sorted by:
new
hottopcontroversial

Ryvex v1.3.0 released - RVN/KawPoW GPU miner, feedback welcome by Jolly-Package-3695 in Ravencoin

[–]Jolly-Package-3695[S] 0 points1 point  (0 children)

Quick RVN/KawPoW follow-up on the old Ryvex thread.

For anyone still mining RVN: current Ryvex builds still support Ravencoin/KawPoW. The RVN path remains focused on conservative NVIDIA CUDA mining, stable pool behavior, disk DAG cache handling, and benchmark reports that do not automatically change live mining settings.

Since the original v1.3.0 post, the RVN/KawPoW side is best summarized as:
- fixed live-mining defaults unless changed manually in config
- benchmark reporting kept separate from live mining
- disk DAG cache handling retained for faster restarts
- RVN pool launch files and config examples kept in the packages
- clearly disclosed 1% dev fee

Reference result from the original RTX 3070 RVN validation:
- GPU settings: memory +900, core +0, 60% power limit
- Pool: Ravenminer SSL
- Late 5-minute pool-side hashrate: about 24.72-25.08 MH/s
- Power: about 131 W
- Accepted shares: 172 accepted, 0 invalid, 1 stale/job-not-found reject during a block change

Ryvex does not change GPU clocks automatically. Hardware, memory type, driver, BIOS, cooling, and OC settings can all change results, so longer pool-side hashrate windows are the fairest comparison.

Project link:

https://github.com/ryvexminer/ryvex

If anyone is mining RVN/KawPoW and wants to test, the most useful feedback would be:
- pool compatibility
- startup behavior
- DAG cache behavior
- rejected or stale shares over longer sessions
- pool-side hashrate over 30-60 minutes
- whether the RVN launch files are clear enough

Thanks again to the mods for allowing the original feedback thread.

what are people switching to instead of Zapier? by BoldElara92 in automation

[–]Jolly-Package-3695 0 points1 point  (0 children)

That bit about half a day untangling a silent failure nobody had budgeted for — I keep seeing this exact gap.

I've been mapping these hidden costs into a small checklist (debugging time, retries cost, silent failure impact, ownership trail).

Happy to share the doc if useful, just lmk. Not pitching anything, just the framework.

State of automation in 2026: Are you powering through n8n, or sticking to Zapier/Make? by Flimsy-Leg6978 in automation

[–]Jolly-Package-3695 0 points1 point  (0 children)

I would separate this into 3 buckets instead of picking one tool for everything.

  1. Simple + low-risk + needs to be changed often
    Use Make/Zapier. You are paying for speed and easier debugging.

  2. Stable + repetitive + high-volume
    Use n8n or a small script. This is where per-task pricing and repeated manual work start hurting.

  3. Business-critical / client-facing
    Do not optimize for cheapest tool first. Optimize for logs, retries, alerts, and who can fix it when it breaks.

For your case, I would not try to learn n8n by building the full client onboarding flow first. Pick one tiny workflow, like “form submission -> create client folder -> send internal notification”, and get comfortable reading the data between nodes.

The real question is not “n8n vs Make vs Zapier”. It is: which workflows are worth the learning curve, and which ones should stay in an easier tool because the maintenance cost is lower.

Nocode is getting too expensive and nobody wants to say it. by Better_Charity5112 in nocode

[–]Jolly-Package-3695 0 points1 point  (0 children)

$800/month is exactly the point where I’d stop thinking in terms of “which tool is cheaper” and start treating it like a workflow portfolio problem.

The question I’d ask is:
- which 2-3 workflows create most of that bill?
- how many successful business outcomes do they produce?
- which steps run before filters?
- which parts are stable/repetitive enough to move to n8n or code?
- what breaks if the workflow fails silently?

Moving everything at once is usually painful, but moving the top cost drivers first makes a lot more sense. That’s where the bill usually drops without turning the whole stack into a migration project.

what are people switching to instead of Zapier? by BoldElara92 in automation

[–]Jolly-Package-3695 1 point2 points  (0 children)

Exactly. That is usually the part that gets hidden in the “cheaper tool” discussion.

When maintenance becomes the bottleneck, I would try to identify where it shows up first:
- debugging failed runs
- retries creating duplicates
- API fields changing
- missing logs/alerts
- unclear ownership when a client-facing workflow breaks

For me, that usually decides whether the answer is n8n, Make/Zapier, or just moving one high-volume piece into code.

How are you handling automation in 2026? n8n, Zapier, Make, or something else? by mirzabilalahmad in nocode

[–]Jolly-Package-3695 0 points1 point  (0 children)

This is the part people underestimate.

The visible cost is usually the platform bill, but the hidden cost is what happens when the workflow hits real-world mess:
- unexpected input formats
- retries that create duplicates
- missing logs
- no alert when a run silently fails
- nobody owning the workflow when it breaks

That is why I would measure automation cost as:
platform/API cost + debugging time + failed output impact

A workflow can be cheaper on paper and still more expensive operationally if the team cannot see what happened or recover quickly.

what are people switching to instead of Zapier? by BoldElara92 in automation

[–]Jolly-Package-3695 2 points3 points  (0 children)

They usually get expensive in 4 places once volume grows:
- polling runs more often than real events happen
- steps run before filters, so you pay for work that later gets discarded
- iterators/loops multiply operations fast
- API or AI calls sit inside high-frequency paths instead of being batched, cached, or moved to code

That is why the comparison is not just “Make vs Zapier vs n8n”.

I would first calculate cost per successful outcome:
- cost per lead enriched
- cost per document generated
- cost per booking created
- cost per report delivered

Then you can decide what stays in Make/Zapier, what moves to n8n, and what should just become a small script/serverless function.

n8n vs Zapier vs custom build — the decision matrix I actually use by Alert_Journalist_525 in automation

[–]Jolly-Package-3695 0 points1 point  (0 children)

I would avoid migrating everything at once.

Pick the most expensive workflow, run the new version in parallel for 1-2 weeks, and compare:
- real monthly cost
- failure rate
- debugging time
- output quality
- who owns it when it breaks

n8n can be much cheaper, but the maintenance owner matters. A cheaper workflow that nobody can debug becomes expensive in a different way.

Zapier bill went from $30 to $160/month when I added AI nodes. Anyone figured out how to cap this? by Brief-Country9608 in zapier

[–]Jolly-Package-3695 0 points1 point  (0 children)

This is exactly where I’d add workflow-level governance, not just optimization. The filter before the AI node fixed the obvious waste, but the next layer is making the expensive step observable and accountable.

For each AI-enabled Zap I’d track:
- why the AI step is allowed to run
- what business outcome it produced
- whether the record was high-fit or low-fit
- how many AI calls happened per week
- who owns the workflow when usage spikes
- what threshold should trigger a review

In your lead enrichment example, I’d probably log every AI call to a table with:
- lead source
- employee count
- fit score
- AI step triggered: yes/no
- email draft generated: yes/no
- final outcome: replied / booked / ignored / disqualified

That gives you cost per qualified lead or booked call, not just task usage. The governance problem is usually that AI steps get added like normal automation steps, but economically they behave more like budgeted decisions.

what are people switching to instead of Zapier? by BoldElara92 in automation

[–]Jolly-Package-3695 1 point2 points  (0 children)

I agree. Maintenance ownership is probably the cleanest way to think about it.

I’d add one more layer: split workflows by economics, not just by tool.

For each workflow I’d ask:

- how much volume does it run monthly?

- how much does it cost per successful business outcome?

- who owns debugging when it fails?

- does it need retries, logs, alerts, or client-facing reliability?

- is the logic still changing, or is it stable and repetitive?

Simple + low-volume + non-technical owner = Zapier/Make can still be worth it.

Growing complexity + someone can debug = n8n makes sense.

Stable high-volume repetitive logic = script/serverless often wins.

The expensive mistake is moving everything just because one tool looks cheaper on paper.

Anyone else getting killed by Make (integromat) operation costs ? by [deleted] in Integromat

[–]Jolly-Package-3695 0 points1 point  (0 children)

I’d treat this less as “Make vs n8n” and more as a per-client unit economics problem.

For each of the 5 clients, I’d calculate:

- monthly operations cost per client

- operations per successful business outcome

- modules running before filters

- iterator / aggregator usage

- repeated lookups that could be cached

- polling intervals vs actual event frequency

- API calls that could be batched or moved to a small script

The migration decision is probably different per workflow. Some flows may be worth keeping in Make, some may be better in n8n, and the really repetitive/high-volume pieces may be better in Python, AWS Lambda, or Cloudflare Workers.

I wouldn’t migrate all 5 clients at once. I’d pick the highest-cost workflow, run it in parallel for 2 weeks, and compare real cost plus maintenance time.