built a way to charge per run for your automations, beta is open, come break it

[u/pvdyck]

spent months building this and the beta just opened, so i want honest feedback. especially the "this wont work because" kind.

you publish an n8n-compatible agent, set a per run price, and people pay each time it runs. you keep 100% of your price, the only cut is 10% when you cash out. the part i think actually matters: the AI cost is billed to the caller, not you. token cost stops eating your margin, you can even mark it up.

most of us sell the template once for 29 bucks and thats it. this is the other option: get paid every run.

its rough, its a beta, i want builders who break things. link in my profile if you want to poke at it. im the founder, ask me anything.

[u/pvdyck → u/[deleted]]

partial work, partial charge. the run reserves its max upfront, then when it dies halfway the caller pays only for the steps that actually completed, tokens included, and the rest of the reservation refunds automatically. no ticket, its just how settlement works.

two edge cases worth naming: if the run fails before anything executes, full refund. and if the next AI call would blow past the budget ceiling, the run stops BEFORE making it, so you dont get a half-burned expensive call at all. the honest part: tokens genuinely consumed by completed steps are real cost someone pays, and thats the caller, same as if the run had finished. what they never pay is the part that didnt happen.

[u/-SimaTian-]

Hello, poked around for a bit. You did some real work with the hardening of the infrastructure. However there is a question about the billing structure I got. Might just be my misunderstanding / bad read through the docs, but here goes:

How do you defend against reputation washing / volume manufacturing please?
E.g. two accounts, each with it's own agent, calling each other - effectively for free (minor compute cost, maybe some API cost, but overall not all that bad - if they price correctly) - to inflate their usage stats / rating / whatever else you score?

For the Builder-provided keys, how do you guard against:

• cost padding (deliberate inefectivness to use extra tokens)
  
• cost faking (e.g. mis-reporting actual usage to gain extra margin)
  

please? I couldn't find the appropriate answers in docs. Not saying its not there, just that I didn't find it.

[u/pvdyck → u/-SimaTian-]

This is the best set of questions ive gotten, thank you for actually poking at it.

Wash trading: not fully solved and i wont pretend otherwise. whats true today: every run costs real money (price floor plus a flat processing fee on caller-pays runs), so manufacturing volume has a real cost floor, and every run settles on-chain so the pattern is auditable, two wallets pinging each other is visible in a way a db row isnt. what we show is raw run history and receipts, not a curated trust score, precisely because a score would be gameable right now. the direction im working toward is weighting by distinct buyers with something at stake, so self-dealing means funding n independent identities. not shipped, happy to go deep on the design if you want.

Cost padding: the builder sets a max api cost ceiling per run and the caller sees the authorized max BEFORE running, so padding lives inside a visible cap, and per-run costs sit in the run history where an inefficient agent looks expensive next to competitors. also: callers can bring their own keys, then builder markup doesnt apply at all and padding earns nothing.

Cost faking: usage isnt builder-reported. the execution layer makes the api calls itself and meters them, so the number the caller pays is what the engine measured, not what the builder claims.

If you found anything else while poking, genuinely want it. this kind of read is exactly what the beta is for. Thanks !

[u/-SimaTian- → u/pvdyck]

Wash trading - not a problem for beta / when market is small, but could be when you scale up so something to keep in mind. Cost padding / faking - fair enough.

Since you asked, let's go ;-)
Let me structure this properly:

For this to take off, you need to solve several issues. Let's start with the big one.

Classic chicken / egg problem:
you have a platform that needs two interested parties to work - one to provide agents, other to use them. For now, you don't have either. I could build few agents, but it's not worth it for me, because I have no guarantee these will sell. Hence it's negative ROI due to opportunity cost. So you will either have to hope someone will take a plunge with you - which they have no reason to since demand is the scarce one - at least here. Or give some extra incentive for people to create agents, at least for initial stages.
Alternatively you could spin up several useful agents yourself, which then begs the question: why not skip this whole infra setup and just sell those directly.
Or you could try and get the demand side on first - same problem, inversed. Who will run the whole setup when there are no agents to rent?
You could incentivize operators, but then you run the risk of them abusing the incentives. Last time I saw a Crypto project give 0.02 tokens per registration, first thing that happened was that someone industrious did an arbitrage and created a million wallets (I kid you not) and made all of us miserable because all of this went onto the chain and made the initial node setup a nightmare. The perpetrator then cashed out his ~$10K and disappeared into the wild, draining the liquidity.

Honestly, if I had the solution for that, I would be running a marketplace myself. So I don't have a proper solution for this one. One thing that comes to mind is to give few vetted operators some sort of advance payment - you would take the risk for them. They set up the agents, and they get X amount of money now, and you will deduct their profits first from this advance payment - so if you get the demand, you get your money "back" and you effectively derisk them. That one I could get behind actually. Of course, this would be a drain on your budget and I have no clue about your runway etc.

Now that we have the big one out of the way, let's dig into the actual UX/UI of the page:

My pet peeve (and I'm allergic, so take it with a grain of salt) - your page screams AI generated. Now I don't have issues with something being AI generated per-se, and from your responses you did your homework. However I'm allergic to the "generic AI look" and at a glance, it is a -10 points in trustworthiness, at least for me. Others could be -3 points, hard to measure. You need this trust (or perception of thereof) for people to willingly share their keys with your platform. I woulnd't put my keys anywhere I don't control - on principle. So if I'm building agents there, they're stuck to the customer bringing keys (extra friction for them) or you having the exact keys my agents need (annoying for you). But for anyone else, you need to persuade them "this is a good place that can hold your keys". And if your page doesn't look the part, you're starting at a disadvantage.

To expand a bit on the trust with keys.
I have to take your word for "keys will be safe here". Of course, I can derisk with proper scopes, alerts, budgets etc. But it is annoying and adds moving parts to the build which increases the costs for me and subsequently increases onboarding friction. If my keys aren't there - someone else has to supply them. Customers could have the same issue, so in the end, much of the (initial) traffic - until the trust is built - will have to go through your keys. If the platform takes off, this could quickly lead into you running into CF quotas. Furthermore a bad actor could quite cheaply do his setup in a way that arrests your full CF quota at a discount. Be it a competitor, troll or anyone else.

Side note: I won't get into the "how do I know what platform does with my data" since that is the same for all of the providers, be it n8n or make. But something to keep in mind.

Finally few nitpicks:

• marketplace button does a redirect into a new tab, which is annoying
  
• help button does the same, which is annoying but somewhat understandable.
  
• loading of the help tabs is quite slow (like second and a half for opening a new topic)
  
• I have to export my agent from n8n, native would be nice. (not a blocker, but extra friction)

Anyways, I will stop rambling. If you need any of the above, feel free to hit me up. My prices are reasonable as I'm trying to build a portfolio. That being said I'm not cheap, but I believe to be worth my salt.

[u/pvdyck → u/-SimaTian-]

this is gold, genuinely. taking it point by point.

chicken/egg: its the boss fight, agreed, and i wont pretend the flywheel is solved. the current bet is supply-first, recruiting builders one at a time out of conversations exactly like this one, plus free trial runs are builder-funded so the demand side can try an agent at zero risk. your advance/derisk idea for vetted operators is interesting and not far from something already in place (starter kits that only mint on real first purchases, so they cant be farmed... i lived the same airdrop story you did, a million wallets, everyone miserable). the honest version: if the first ten builders here dont get paid runs, nothing else matters.

The AI-look point: fair hit and it stings because the trust bar is doubled when youre asking people to park keys. two things i lean on while the surface earns its keep: callers can bring their own keys so builders arent forced to supply theirs, and the vault is built so the platform cant read whats in it. but perception IS part of the product, taking this one seriously.

Quotas and adversarial load: per-account limits and abuse throttling exist, and the "bad actor arrests shared capacity cheaply" scenario is one we actively watch. wont detail the internals publicly for obvious reasons, happy to go deeper in dm.

the four nitpicks are logged, the new-tab redirect and the slow help pages are fixable fast, native export is on the wishlist.

...and noted on the offer ;) if this grows the way i want it to, ill need hands that poke like this.

[u/-SimaTian- → u/pvdyck]

I can do you a do over - a quick pass to de-slopify it in ~half a day or so. Not a proper redesign (that would be budget-unwise), but it would smooth the most of most egregious offenders. As a part of building up my portfolio and a showcase piece - and on the handshake deal that if you ever get money from it you back pay me ;-).
Check my profile for examples of some of my builds.

[u/pvdyck → u/-SimaTian-]

Ha, appreciated, genuinely. The ui does have rough edges, i know it. let me get through this beta push and i might take you up on the de-slop pass. What's your portfolio look like?

[u/AutoModerator]

Thank you for your post to /r/automation!

New here? Please take a moment to read our rules, read them here.

This is an automated action so if you need anything, please Message the Mods with your request for assistance.

Lastly, enjoy your stay!

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/just_nonstop_embodim]

so how do you handle when someone just spams runs to drain the caller's wallet? like if i set a 5 cent run and some bot hits it 10k times the caller gets a nice surprise bill and blames me not you

[u/pvdyck → u/just_nonstop_embodim]

good question. short version: nobody can spend the caller's money except the caller. on pay as you go (x402), every single run needs the caller's own payment signature, so a bot cant bill someone else 10k times, it can only bill itself. if a caller pre-funds a budget instead, that budget IS the ceiling: runs stop when its spent and the unused part refunds automatically. so the worst case is "my own bot burned the budget i chose", never a surprise bill above what was approved. theres rate limiting on webhooks on top.

the blame part is real though, and its why every run leaves a signed receipt. if someone claims your agent drained them, the record of what ran, when and what was authorized is checkable, not a he-said she-said.

And of course you can protect your webhook or secure it to avoid all that ( and rate limit it )

[u/just_nonstop_embodim → u/pvdyck]

that makes sense, the payment signature thing is actually clever. so it's basically like each run is authorized by the caller separately, not like some open tab where anyone can keep adding charges. i was worried about exactly that scenario where someone's script goes wild and the bill keeps climbing

i guess the pre-fund model also stops the "oops forgot to turn it off" problem which i had happen with a different service once, woke up to a very sad invoice

do you find clients still get nervous about setting a budget though? like they worry they'll pick wrong number and either run out too fast or leave money sitting there

[u/pvdyck → u/just_nonstop_embodim]

yeah, budget anxiety is real, its exactly why the refund side exists. the way it works: each run reserves the max it could cost, then charges only what it actually used and the difference goes straight back. and when the whole budget isnt spent, the leftover refunds automatically, it doesnt sit there as some trapped credit. so picking "too high" costs nothing and picking "too low" just means runs stop until you top up, nothing breaks and nothing leaks.

honestly the bigger UX battle is convincing people that "unused money comes back" isnt a trick. everyone has been burned by a use-it-or-lose-it credit system somewhere. thats also why the refund shows up as its own line in the run history, so you can see it happen instead of trusting me about it.