Product Hunt 每日热榜 2026-07-13

PH热榜 | 2026-07-13

#1
Osaurus
Open source agents that run 100% locally on your Mac
578
一句话介绍:Osaurus是一款为Mac用户打造的完全离线、开源AI代理平台,让用户无需将文件、记忆和上下文上传至云端,即可在本地执行自动化任务、管理日程并调用任意模型,彻底解决隐私泄露和订阅捆绑的痛点。
Open Source Privacy Artificial Intelligence GitHub
本地AI代理 开源 Mac原生 隐私保护 离线运行 AI自动化 内存持久化 苹果生态 模型切换 开发者工具
用户评论摘要:用户普遍称赞本地运行和隐私性,但关注点集中在:需视觉化活动日志以增强信任;如何跨会话保持本地记忆;本地模型与云端模型动态路由的可行性;以及模型更新机制。部分用户期待更易用的入门教程以降低使用门槛。
AI 锐评

Osaurus的野心在于重新定义“AI主权”。它通过Swift原生、离线推理和本地存储,切中了大型SaaS平台对数据控制权的信任危机。核心价值并非提供更“强”的模型,而是构建了一个完全由用户掌控的Agent生态:从文件操作、系统自动化到子任务委托,全部在本地沙箱内闭环执行。这种“黑箱透明化”的信任契约,比云端的“黑箱高效化”更符合未来隐私优先的趋势。

然而,其局限也很明显:依赖Apple Silicon的算力天花板,意味着复杂任务(如多模态分析、长链推理)仍会暴露对云端模型的依赖。虽然提供BYOK模式,但本质上未解决核心算力瓶颈。社区反馈中“分散注意力的功能设计”——让模型去生成PPT或3D游戏——更像是技术演示而非核心场景,这需要警惕产品陷入“炫技”而偏离真正的实用性。目前,它更适合开发者、隐私敏感用户以及希望摆脱SaaS依赖的专业人士。对于普通用户,Dino UI和实时审批门是加分项,但“安装大模型+配置Agent”的启动成本仍然不低。Osaurus的长期价值,在于它能通过开源社区构建出一个类似Home Assistant之于智能家居的“本地Agent生态标准”,而非仅仅做一个漂亮的Mac原生客户端。

查看原始信息
Osaurus
The native macOS harness for AI agents. Any model, persistent memory, autonomous execution, cryptographic identity. Built in Swift. Fully offline. Open source.

Hey Product Hunt, I'm Terence, founder of Osaurus. I spent 20 years shipping software at Netflix, Tesla, and Zillow before going all in on this.

Own your AI. Osaurus is an open source AI agent platform that runs on your Mac.

MIT licensed, native Swift for Apple Silicon. No account, no subscription, no Electron.

We started as Dinoki, a 5MB desktop dinosaur, and grew into a full agent platform through open source community feedback. Now at 7K+ GitHub stars and 175K+ downloads — all by word of mouth.

The problem: most AI assistants run on someone else's server.

Your files, memory, and context leave your machine every time you use them, usually behind a monthly subscription.

Osaurus keeps all of it on your Mac.

What that means in practice:

  • Agents read your Calendar, look up Contacts, send iMessages, and work with your real files

  • An isolated sandbox writes and runs code, producing real files on your desktop: images, PDFs, presentations

  • Every action goes through an approval gate. You see what the agent wants to do before it does it

  • Local models run fully offline. We built our own Swift MLX runtime, no Python underneath

  • Want a frontier model? Bring your own key (OpenAI, Anthropic, Gemini) or use pay-as-you-go Osaurus Cloud. Either way, your memory and context stay local

It's free and always will be.

16GB of RAM gets you started with local models, 24GB recommended.

Try it at osaurus.ai. Download takes seconds, no account needed.

I'll be here all day answering questions. My favorite Osaurus hack is to set up Agent DB and self-scheduling to create a personal dashboard!

28
回复

@tpae Love the focus on being truly native to macOS instead of another cross-platform wrapper. Supporting any model, persistent memory, autonomous execution, and offline operation—while being open source and built in Swift—makes this especially appealing for developers who value privacy, performance, and full control. Best of luck with the launch!

0
回复

@tpae Cheers. Long time looking into this project and using it on my machine. It is really well thought out, detailed and with so many options and use cases. Best of all to you and everyone involved in the Osaurus project.

5
回复

@tpae Congrats!

I used to piece my AI system together from different apps just to get a working agent, but Osaurus was the all-in-one solution for me. It just works flawlessly.

For my use-case, I use it with a local AI as an autonomous assistant for my vacation rental business, so it helps me with emails, marketing and general organization.

Thank you so much for this project and good luck!

4
回复

So stoked to unveil @Osaurus to the Product Hunt community!

I've been a long-time advocate of open source (going back to the launch of @Mozilla Firefox in 2004!).

I've followed products like @Ollama and @LM Studio but neither is Mac-native nor have the character of Dinoki, the little guy I originally fell in love with, long before Petdex existed:

While I'm a big Anthropic and OpenAI user, I also believe strongly that local, open source AI is the future of computing, and Osaurus is the user-friendly app bringing this to everyone.

Osaurus is like the Firefox of open source AI!

You can download and run the latest models from @Z.ai @Qwen @Gemini (Gemma), or BYOK.

Now's an awesome time to give Osaurus a try, and if you're feeling bold — the beauty of open source means we'd love your contributions!

15
回复

Congrats on the launch! I like that it runs locally and asks for approval before each action. For anything touching Calendar, Contacts, and iMessage, that's the combination I'd want before granting access.Curious how you handle memory and context across sessions while keeping it all on-device.

3
回复

Thank you@alieksia !

Everything is stored locally on your file system, including chat history, memory, and everything else. Your Mac has the capability to run it's own inferencing, it can distill memories too, and process it's own embeddings for dynamic contexts.

1
回复

Congratulations on the launch! Being offline and private is something that makes Osaurus really stand out.

I'm a bit of a dinosaur myself and always wonder - would educational content be useful for attracting users like me? A bit old-fashioned, not using agents yet, and not sure how to apply them to real use cases.

And speaking of dinos - I love the character design and animation on your website! Which dino is your favourite? Is it the same one you loved as a kid?

It could also be really fun to have a YouTube channel where dinos explain how to use agents in an easy and playful way.

2
回复

@julia_shtogren Thank you for your kind words!

We're in the process of building out YouTube content for new users like you, and our goal is to make it simple enough for you to get started without needing complicated tutorials. Happy to answer any questions in our Discord if you need additional help.

I love our green dinosaur (his name is Dinoki), and I recently rediscovered my love for dinosaurs once my son got into it.

1
回复

honestly this looks great for mac users, the offline angle is a big plus. one thing i'd love to see is a simple visual diff or timeline for what the agent changed locally, like a little activity log you can scrub through. would make it way easier to trust what it's doing in the background

2
回复

@doyranl58403 That's a great suggestion! If you are using sandbox to edit files, it does keep an internal log of changes. You can ask the agent to undo a file operation, and it will do it. We just need to make it stand out visually

1
回复
@tpae knowing what it is doing in some visual way to gain trust in the effectiveness is a great idea. Would use just for that imo. Love this!
1
回复

Hi, this is cool. What are some exciting and unique ways that people are using Osaurus and is there a roadmap?

2
回复

Hey @andrea_j , great question!

Honestly the sandbox stuff surprises me the most. Agents spin up an isolated Linux VM and make real things: slide decks, 3D games, deployed websites. Recently I watched an agent write its own skill to solve a task, which was a little surreal.

Roadmap: personal AI you actually own. Agents, memory, skills that live on your Mac and compound over time. Lots left to build.

Curious what you'd want your Mac to do on its own!

0
回复

Swift-native, fully offline, and open source is a rare combo — most agent harnesses assume you're fine piping everything to the cloud. The cryptographic identity piece is intriguing; I'd love to hear more about how persistent memory works across sessions and whether it's local-only storage. This feels built for people who actually care about owning their stack. Nice work.

1
回复

@kelly_king3 Thank you Kelly! Memory is stored locally on device, using local embeddings. It works fully offline as well. We believe everyone should own their AI.

0
回复

Does it take a lot of space in my computer?

1
回复

@doganakbulut Depends on which model you download, but it ranges between 6GB ~ 20GB for smaller models, and could be more than 200GB+ for larger ones

0
回复

Just discovered @Osaurus on X

  • Used my ChatGPT Pro sub

  • Recognised my local MLX models from LM Studio

  • 💜 Dino avatars

1
回复

@karthikeyan_ranasthala Welcome to the community! Thank you for your support!

0
回复

How do you plan to handle model updates and ensure the agents stay current with the latest AI advancements without requiring a full app update?

1
回复

@aymnart We do have auto update enabled, and we do daily updates. Our builds are fully standalone, it doesn't require any servers and you can run it locally offline. You can choose not to upgrade, but your app will fetch our latest models catalog from our hugging face.

We quantize our own models and also tune our evaluations every time a new model is dropped. We've been one of the pioneers in releasing quants for smaller models. We're one of the few that is supporting range of models including the latest Hy3.

0
回复

I see you also made apple script models. What was the thought process there? I know many similar apps use applescript just as an escape hatch for terminal calls.

1
回复

@conduit_design We built Computer Use first, and it was great for what it is (clicking around the screen). We wanted to push automation a bit further, and came up with a solution to run AppleScript using local models. Since AppleScript allows chaining apps, we thought it will produce a very rich experience in automating your Mac. It's a little bit too powerful though, so be careful. It emptied my trash bin one time and I got scared.

You can read about our process here: https://osaurus.ai/blog/applescript-models

0
回复

How good it the macuse skill? Can the mac be controlled via local LLM? or does that require better models only available via cloud? If local LLM is possible with mac-use skill, what requirment would support local mac-use skill? Btw looooooove the Laundromat Afternoon theme 😸

1
回复

@conduit_design Great question! We run our own evaluation suite for each local model using community sourced compute. I have to say, it's decent enough to use, some models are better at it than others. Strange though, if it's good at computer use, then it's lacking in agentic coding, and vice versa. You might need to switch between two models to have best of both worlds.

https://github.com/osaurus-ai/osaurus/blob/main/reports/COMPATIBILITY.md

1
回复

The approval gate is nice. One action, easy call. Wondering once an agent chains 15 steps to build a deck or deploy a site, does every step stop and wait for me? Fantastic launch!

1
回复

@artstavenka1 Thank you so much! You can always "Always Allow" on some of those actions and it won't ask you again. I would leave the destructive ones to "Always Ask" just in case!

1
回复

@tpae Huge congrats on bringing Osaurus to PH! 🎉

For users running hybrid workflows (e.g., small local model like Gemma for simple file/routing tasks, but switching to BYOK Claude/OpenAI for heavy reasoning), can an agent dynamically route tasks between local and cloud models within the same workflow, or is an agent fixed to one specific model backend?

1
回复

@franz_briones Yes! We recently launched Subagents, which allows your agent to use local or remote model to delegate tasks to another local or remote model. It doesn't do intelligent routing yet, but if your reasoning model is capable of identifying which task is good for which model, should be able to set up routing logic via system prompts.

2
回复

Finally a Swift-native agent harness that doesn't feel like a wrapper around a Python script. The persistent memory across sessions actually held context from yesterday, which surprised me.

1
回复

Hey@hargdeansa20796 I'm tired of wrappers too. Mac users deserve something better. Which is why we built Osaurus.

Let us know if there's any feedback or suggestions on how to make it better.

0
回复

@Osaurus Congrats on the Launch. The Osaurus dino is super cute.
I have been waiting to try locally run models and see the performance. What the hardware requirement? is a M4 Mac mini 16gb enough? Eager to try it.

1
回复

Hey @roopesh_donde !

16gb would be usable, although 24gb would be recommended. I would suggest using Gemma 4 e4b, it's not crazy smart like the others but is able to call tools in a meaningful way. Let me know if you run into any questions!

2
回复

How is this different with Codex or Claude Code?

0
回复

Huge congrats on the launch, @tpae ! Love the offline-first approach. One thing I’d find useful: a visual activity log to scrub through what the agent did locally. Any plans for that?

0
回复

Mac-native and local is the combo I keep wanting, the Firefox-of-local-AI pitch landed. Practical question: what's the real memory footprint running one of the mid-size models on, say, a 16GB machine, does it stay usable or does it eat everything and make me quit my other apps? That's usually where "runs locally" turns into "runs locally if you bought the maxed-out box." Nice to see something leaning open source instead of another closed wrapper.

0
回复

Congrats on the launch. The approval gate feels like the right trust boundary for an agent that can touch files, Calendar, Contacts, and iMessage. Iâm curious how you think about permissions once someone has several agents or projects: are you aiming for per-action approvals only, or eventually a project-scoped policy where an agent can access one context but not another?

0
回复

@wesc Right now we're keeping it simple, per-action approvals seems to cover the highest surface area. In the future, we can get more granular, as agents earn more trust.

0
回复

That makes sense. Per-action approval is a practical default when the trust surface is still broad, and the idea of gradually earning more granular permissions feels like the right path. It keeps the user in control without forcing a complex policy model on day one.

0
回复

this is one of the more compelling "local AI agent" pitches I've seen, the approval gate before every action is the part that actually matters to me, most of these tools just yolo the agent loose on your filesystem. question on the self-scheduling piece you mentioned - does that still fire if the Mac is asleep or the lid is closed, or does it need to actively be awake/plugged in for scheduled runs to trigger?

0
回复

@omri_ben_shoham1 Thank you for your feedback! It does require your Mac to be on and awake. It will queue it up until your system comes active.

0
回复

the approval gate plus "always allow" per action is the right default, but the part I'm actually curious about is the open source contribution angle - if community members start shipping shareable agent skills/plugins that get access to iMessage or Contacts, is there any review step before those get trusted, or is it on the user to audit what a downloaded skill can touch before installing it

0
回复

@galdayan We accept contributions but we make sure it's strict to our code standards. We have artifacts that allows agents to run through series of checks before making the PR. We set our standards high for developer contributions

0
回复

Local-first agents is the direction I keep hoping wins. The cryptographic identity part is interesting — most agent frameworks treat identity as an afterthought. Curious how heavy it gets memory-wise with a couple of agents running on an M-series Air?

0
回复

@alex_tomilin How big is your Air? I would suggest having minimum RAM of 16GB, but 24GB is recommended. Depending on the model you choose but it could take up anywhere between 8GB ~ 12GB RAM during active usage.

0
回复

Nice. If Qwen (or some of its models) are still open-source, which is my guess, I can confirm it works fine on a Mac Mini M3 for doing automation tasks on websites, DOM manipulation...

0
回复

@elias_iturri Qwen is a beast of a model. One of the best released for it's size

0
回复

Downloading to check this out now! Just the branding of the dinosaurs is unique enough to pique my interest, would love to know where you got the idea to use them. Make the internet fun again!

0
回复

@rick_mcclelland Let's make it fun!

My son was getting into dinosaurs (he's turned 3), and I wanted to build something fun with AI. I built Dinoki (pixel dinosaur desktop AI companion), and realized there's a growing need to run local models (for costs and privacy). Dinoki will be central to what we do, so when we built Osaurus, we decided to keep the same branding.

0
回复

Congrats on the launch! With the approval gate on every action, does that mean autonomous runs stop and wait a lot, or is it smart about only flagging the risky stuff like sending a message or running code?

0
回复

@irahimiam It's about having control, and you will be asked each step, but you can always choose "Always Allow" for specific actions you feel comfortable with.

0
回复

You describe Osaurus as an AI agent platform rather than just an assistant. Long term, do you envision users interacting with a single persistent agent that accumulates years of context, or a collection of specialized agents with separate memory and identities?

0
回复

@tarqiya_forgah There's use cases for both, having a single agent (or orchestrator) that accumulate years of context, and having multiple agents (or subagents) that are specialized with contexts that can perform specialized tasks.

What we're discovering now is, local models trained with specific set of tasks, they are capable of performing at the same level (if not better) than frontier models for those tasks.

We believe this is just the beginning of a local-first AI harness. We call it a platform because we expect others to join us in shaping what this future would look like.

0
回复

The Mac-native angle is the part that stands out. Ollama works, but it always feels like it is renting space on the machine rather than living on it. What I would want to know is how model management holds up once people start pulling in the bigger local models, is there a clean way to swap them without eating all the RAM. Either way, local-first AI getting a friendlier front door is good for the whole space.

0
回复

@liana_preston Thank you for the feedback, totally agree that local-first AI needs to get more attention. As AI enthusiasts, we need more choices on how to use our AI, and in my opinion, owning your AI is the best option. We allow you to own your AI without having to rent them.

Our harness has been tuned to work with local models efficiently, if you have a larger mac, we support multi model residency (allowing you to warm up multiple models at a time), but if you have a smaller one, we make it efficient to load and unload them.

Our core idea is that harness is what makes local AI useful. We spent our time optimizing our harness for local models, and it's capable of doing complex agentic tasks.

0
回复

Using Osaurus every day and really appreciate all the hard work. It's my go-to for when I share Venice API keys with family and friends to introduce them to AI. I'm looking forward to being able to use image gen and TTS with a cloud or local server url. I'm using Venice for LLM in Osaurus, and it would be nice to use their image and speech models as well. I'm also setting up my 5090 GPU PC with image gen and fish audio TTS, and if it could be a local network server for Osaurus image and speech gen like it is for local LLM, that would be great for local!

0
回复

@ryot Hey there! Thank you so much for showing up and giving us support. We're working on those features and should be available in the next few releases. I will keep you posted!

1
回复

the fully-offline bit is the whole selling point for me tbh... most agent tools are just api wrappers that fall over the second the wifi does. running local on the mac with persistent memory is an actual edge, not a checkbox... swift instead of yet another electron thing is a nice touch too.

0
回复

@alex_watson2110 Exactly. Electron is purely for companies to expand their reach, for Mac users, we're getting the shorter end of the stick. Mac users deserve better. That's why we built it in Swift.

0
回复
#2
AgentKey
One-stop live data marketplace for your agent
504
一句话介绍:AgentKey是一个MCP插件,能让AI代理通过一条指令接入搜索引擎、社交媒体、金融、电商等实时外部数据市场,无需管理多个API密钥和集成配置。
Productivity Artificial Intelligence Data
AI代理工具 MCP插件 实时数据市场 API聚合 自动故障转移 意图识别 AI开发工具 数据集成 无代码配置
用户评论摘要:用户普遍赞赏自动故障转移功能,认为它让代理不会因上游API宕机而中断。核心反馈集中在:1)请求检索层误选端点时可能出现静默错误,需增强透明日志;2)社交数据来源需明确是否合规(回复称来自官方合作源而非爬取);3)建议在自动切换时显示切换原因。
AI 锐评

AgentKey解决了一个真实但被低估的痛点:AI代理有了大脑,却仍然没有“眼睛”。它将构建数据链路的复杂性打包成一个插件,让代理不再局限于训练数据或“死”API,这确实是一个务实的进步。

从技术架构来看,其核心亮点并非聚合的1800个端点,而是意图识别层。将工具发现的Token消耗从35000降至1500,并训练专门的检索模型,这证明了团队对MCP协议在规模扩展时性能瓶颈的真实理解。值得注意的还有故障转移设计:它不仅做被动路由,还基于延迟和错误率主动切换,并以语义匹配优先于速度,这个细节处理超越了多数聚合器。

然而,真正的价值验证还差关键一锤。工具选择的静默错误是硬伤——当模型选错端点,用户看到的只是错误结果,却无法归因。创始人诚实地承认这一点,并承诺将检索排序透明化,这是决定产品能否从“玩具”走向“工作台”的分水岭。如果用户无法信任代理的“眼睛”,那么再多端点也无意义。另外,定价模型和社交数据合规性的追问尚未完全解答,这在实际生产环境中是潜在雷区。

本质上,AgentKey还不是数据搜索引擎,而是数据的前置路由器。它降低了门槛,但尚未消除风险。对于想要快速原型验证的开发者,它现在是最好用的工具之一。对于需要数据可审计、零容错的生产系统,它还有一段路要走。这个产品最聪明的不是技术,而是变现方式——在所有代理都在寻找数据入口时,它选择成为那个入口的收银台。

查看原始信息
AgentKey
AgentKey is a plugin that connects your agent to live external data in one command. Install it into Claude Code, Codex, OpenClaw, or any MCP-based agent and instantly unlock access to search, web pages, social platforms, finance, e-commerce, business and crypto data. No integrations. No setup. Auto failover keeps workflows running.
Hi Product Hunt, I'm Mogu, founder of Chainbase. Today I'm really happy to share the newest project out of our lab: AgentKey. It's been in private beta for a while, and a few thousand people have been using it and helping us shape it along the way, so it finally feels ready to put in front of you here. Here's the thing we kept coming back to. Agents have gotten genuinely good at doing tasks. What they don't have is eyes. They can reason and act, but they can't actually see the live internet, which is where almost all the useful tools and real-time data actually live. So you end up with a strange gap: an agent smart enough to do the work, sitting behind a window it can't look through. And today, giving an agent those eyes is a chore. You wire up one API for search, another for scraping, another for social, another for market data. You babysit a pile of keys and bills, and you basically have to understand the plumbing before you can even start. Most people who'd benefit from this never get past that part. So we built AgentKey. You install it like a plugin, and your agent gets access to a whole marketplace of capabilities behind a single account. No juggling APIs, no keys to manage, no need to be technical. One account, one bill, and your agent suddenly gets a lot more powerful. Right now the marketplace is organized into a few tiers, and it keeps growing: - Everyday tools: search, web scraping, social media - Professional data: finance, crypto, business data - Life and travel: weather, maps, trip planning, and more It already plugs into 20+ of the agents people actually use, including Claude, Codex, Openclaw, WorkBuddy and Cursor. And because everything sits behind one marketplace, if a provider has a bad day your agent can fall back to another source and keep running. We really believe agents are about to bloom into a huge, messy, wonderful ecosystem. What excites me most is that people can finally hand their agents the real, complicated work, not just the basic stuff, and actually trust it to get done. That's most of why we're launching here. It's free to start, no card needed. Please go try to break it and tell me what's missing. I'll be in the comments all day.
16
回复

@yanshuo 

The abstraction layer here is what stands out to me. Instead of worrying about API management, authentication, and provider reliability, developers can focus on building better agents. That’s a meaningful improvement to the AI development workflow. Great work by the team!

0
回复

@yanshuo This is really cool!

0
回复

Makes sense — the pooled balance and QoS shaping clearly need the proxy server-side, and provenance staying in the transcript is exactly what keeps it auditable for me. Follow-up: is local mode with my own upstream keys on the roadmap at all, or is the server-side pool load-bearing enough that hosted-only is the long-term shape?

1
回复

Hey the token math on tool discovery is honestly the most concrete detail in the whole pitch. Going from roughly 35,000 tokens to about 1,500 by training a retrieval layer instead of dumping every endpoint definition into context is a real architecture decision, not just a marketing line, and it's the kind of problem that quietly breaks a lot of MCP integrations once they scale past a handful of tools for sure.


But when the retrieval model picks the wrong endpoint for an ambiguous request, is that visible anywhere, or does a wrong pick just look like a silent bad result downstream?

7
回复

@uddipta Silent wrong pick is exactly the failure mode that matters, so honest answer: the retrieval layer never executes anything on its own. It returns a shortlist of candidates with descriptions into the agent's context, the agent picks one, pulls the full schema for that tool, then calls it. Ambiguity usually shows up as a weird shortlist in the transcript, not a hidden wrong hop, and the agent can just re query with better phrasing. The remaining gap is real though: if the agent picks a plausible but wrong candidate, that does land as a bad result downstream. Today you'd trace it through the console call log. Surfacing the retrieval ranking itself is on the list, this thread has basically been writing our observability roadmap for us.

5
回复

@uddipta Honest answer: right now a wrong pick mostly just looks like a normal result. Explicit errors are easy, the agent sees the failure and retries. Silent bad picks are the hard case and you put your finger on exactly where we're weakest.

The way we think about it, discovery is a loop: find the tool, judge it, call it, then feed the outcome back so the next pick is better. We have the first three. The feedback part is where the real work is, and it's barely started.

The thing that makes it tractable is that we sit in the middle of every call, so we can actually measure this. Which endpoints get picked for which phrasings, where results get thrown away or re-queried, which providers quietly underperform on ambiguous requests. None of that is exposed yet and honestly our own dashboards are thin. But that's the path: make the wrong picks visible in the data first, then drive the rate down.

Good question. Not many people get this far into it.

3
回复

@uddipta Interesting product! I'm also building in the productivity space with FocusQuest. I’m a huge fan of exploring new ways to stay focused and fight digital addiction. Keep up the great work!

0
回复

Hey PH , I'm Cong, Founding engineer at Chainbase here. I've spent the past few months building AgentKey, a one-stop live data marketplace for your agent, and I want to share the three problems that took us the longest to get right.

1. Tool discovery

We sit on ~1,800 API endpoints. If you dump those into MCP as static tools, the agent burns ~35,000 tokens of context just loading the definitions, and it still picks the wrong tool half the time. So we built our own intent recognition layer: the agent describes what it wants in plain language, like "find trending sunscreen posts on reddit", and a retrieval model we trained on our own catalog maps that straight to the right endpoint. Param schemas only load for the one tool it actually picks. The whole flow runs on about 1,500 tokens, and it stays that cheap no matter how many endpoints we add.

2. Every agent wants to be integrated differently.

Claude Code, Codex, WorkBuddy, Openclaw ... we support 20+ of them and each has its own quirks. Our answer is a split architecture: a lightweight skill on your machine that auto-detects whatever agents you have and keeps itself updated, plus one standardized MCP server in our cloud that's always current. You set it up once and never think about it again. New endpoints, fixes, upgrades all land on the server side, so there's no local upgrade treadmill to babysit.

3. Upstream APIs are flaky.

Providers rate-limit, degrade, and sometimes just die. We do QoS-based traffic shaping and automatic failover between providers, so when one goes down the request quietly reroutes to a healthy one. Your agent gets an answer instead of a 503.

I'm around all day, happy to answer anything about how this works under the hood.

6
回复

@lxcong How does billing actually work when you're pulling from 1,800 different providers with different pricing? Is it a flat markup, or does cost vary a lot depending on which data source gets used?

0
回复

The auto failover is quietly the best part. One of the search providers had a bad day last month and my research pipeline didn't even notice.

5
回复

@shirley_mou "didn't even notice" is exactly the bar we set for it. We track latency and error rates per provider and reroute before requests start failing, so if it's working right there's nothing to see. Glad it earned its keep quietly

3
回复

@shirley_mou Ha, we saw that one. A provider went down for a few hours, traffic just moved over. That's exactly why we built it. Your agent shouldn't stop working because someone else is having a bad day. Good to hear it did its job.

3
回复

Hello PH community, I'm Luki, founding member at AgentKey, leading product partnerships. Mogu and Cong covered the why and how, so just my two cents from the partnerships side.

The biggest blocker I keep seeing is that nobody wants to spend weeks juggling multiple API signups, keys, and renewals just to launch one feature.

A few examples:

  • A travel AI team wanted to add flight and hotel pricing. The idea sat on the backlog because no one wanted to set up multiple data providers. With AgentKey, they had it working right away.

  • A fintech startup needed live crypto and market data. They were able to testing with real data within a day, instead of spending weeks signing up for different vendors.

  • A gaming studio was building NPC agents that needed both web search and social context. One integration gave them everything instead of stitching together several services.

That's the part of AgentKey I'm most excited about. We help teams spend less time on account setup and vendor juggling, and more time building the product they actually want to ship.

I'll be around in the comments today if anyone wants to chat about partnerships, integrations, or use cases :)

5
回复

Half my agent demos used to die live because one upstream API picked that moment to have an outage. Failover should be table stakes and somehow nobody else ships it.

3
回复

@jocky Yeah. When a tool breaks on you, you just go find another one. Agents never had that option. No way to discover what else is out there, no place to go looking. So they just die.


That's the gap we're filling. Glad your demos survive now.

1
回复

@jocky Fair question why it's rare. A single-provider API has nothing to fail over to, so the feature can only exist at the aggregator layer, and most aggregators stop at the billing part. The unglamorous half is aligning providers closely enough that a swap doesn't change your output shape. That part ate way more time than the routing logic itself.

1
回复

Tried it yesterday with codex. From install to first live twitter search was maybe two minutes. That's rare for anything involving third-party APIs.

2
回复
@s_cen Thanks Steven! Love hearing that. Getting from install to a live query in a couple of minutes is exactly what we were optimizing for. Hopefully the setup stays ”boring” so you can spend your time building instead of configuring APIs ☺️
0
回复

@s_cen With an LLM in the loop, two minutes means the network part barely showed up. It's a standard remote MCP server under the hood, point and go, and it answers as a plain API too if codex ever isn't your ride.

0
回复

The idea seems terrific, but I think the name falls short of the ecosystem potential, among other things because it does not really make immediately clear what the product does. If you just drop me the name, I'd say it's some agent authentication thing.

No intention to offend you guys or diminish the value of the work behind your product ;)

2
回复

@elias_iturri Appreciate the honest feedback, and no offense taken at all. 🙂 We actually went through a lot of naming discussions internally. Our thinking was that "Key" represents unlocking a whole marketplace of capabilities with a single integration, but you're right that it doesn't immediately convey that on first impression. We'll definitely keep listening as we evolve the product and the messaging.

0
回复

the social media data tier is the part I'd want more detail on - scraping platforms like X or LinkedIn directly usually runs into their ToS, and enforcement can hit the scraper's IP/account rather than the end user. when AgentKey serves social data, who's actually taking on that platform-side risk, is it abstracted away by using official APIs where available, or is it scraping under the hood and you're the one absorbing the ban risk

2
回复

@galdayan We don't scrape under the hood. Social data comes from established vendors, some official APIs, some their own infrastructure, and managing that platform relationship is their core business. What we control is the user side, read-only access, no account linking, no credentials. Upstream enforcement lands upstream, not on you.

2
回复

@galdayan Hi Gal, Thank you for your question. AgentKey is basically the capability marketplace for agents, handling tool discovery, execution, and payments. The truth is, users could already use other vendors to get this data. However, for ordinary users who aren't developers, this is very difficult. That's why we want to solve the problems most people encounter. These services are provided by professional Data Provider, RapidAPI and other devs, so there's no safety risk. And just so you know, the data APIs they offer just pull from the public web, not private stuff. Hope that helps!

1
回复

the interesting part isn't any single integration, it's that the agent gets a whole catalog. my research assistant went from "answers from training data" to "checked five live sources" with zero code from me.

2
回复

@kryptaria Once access stops being a project, the agent starts checking things you never asked it to check. We noticed the same shift dogfooding it ourselves, questions come back with receipts now

0
回复

@kryptaria Well said. We found that once the friction of accessing live data disappears, agents become much more "curious". They stop relying mainly on what they already know and start checking multiple sources by default :)

0
回复

@kryptaria I totally agree! That's exactly why I love using it too. My AI agent is now crushing research tasks way better than ever before. Since it pulls from real-time, reliable data, the LLM hallucination rate has dropped significantly. So glad you discovered it too ^^

1
回复

For research workflows, having FRED + finnhub + yahoo finance next to social sentiment behind the same key is a sneaky-good combo. Macro context and market chatter in one loop.

2
回复

@parsons_wu_real team favorite combo honestly. The fun part is the cross-category stuff, like ecommerce listings plus social chatter for product picking, what's getting hyped versus what's actually selling. Most of the good pairings are probably still undiscovered. Weirder combos welcome

0
回复

honestly the auto failover part sounds super useful, would be great if there was a way to see which data source it switched to and why, like a quick log or notification. that way its easier to trust the results when something jumps from one provider to another.

2
回复

@demet44834 Good call, and framing it as a trust thing is exactly right. Two pieces exist today, the console keeps a full log of every api call, and when a provider is having issues we flag it on the agentkey store page. What's missing is the part you're describing, a marker on the call itself saying it got rerouted and why. That's a genuinely good suggestion, adding it to the list.

1
回复

@demet44834 Love this suggestion. The failover is one of those features you don't appreciate until something breaks. Seeing a small note like "rerouted from X due to timeout" would be great for transparency without getting in the way! Thank you Demet!

1
回复

Been using this in claude code for a couple weeks. The thing I didn't expect is how much it changes what I ask my agent to do. I stopped thinking "can it even access that" and just ask.

1
回复

@fei_li5 Thank you Eric! That's the line we've been trying to articulate for months and you just wrote it for us.

0
回复

Congrats on the launch! The "one command, no integrations" angle is the part that stands out — connecting live data usually means wrangling a dozen MCP configs and babysitting them when one goes down. Curious how the auto failover picks its fallback source: is it latency-based, or does it rank by data freshness? Either way, this looks like a real time-saver for anyone building agents that touch the open web. 🚀

1
回复
@kelly_king3 Thanks Kelly! It's actually two layers. We rank by relevance to the request first, then by live provider health (latency, error rates, availability) among equivalent providers. That way the best semantic match is chosen, but unhealthy providers automatically move down the list instead of becoming a bottleneck.
0
回复

@kelly_king3 Closer to the first, but latency is only half of it. Fallback candidates rank on two keys: how well a source matches what the agent actually asked for comes first, then live health stats, which is where latency and error rates live. So the replacement is the best-fitting healthy source, not just the fastest one. Freshness we treat as a property of the data type rather than a ranking signal, a price feed and a search index just run on different clocks. And the babysitting a dozen configs life you're describing was the exact thing we set out to retire.

0
回复

@lxcong ok that's the part I was missing - the explicit failure + re-fetch-schema-on-retry step. that's a smarter design than I gave it credit for, avoids the "silent swap" problem entirely instead of just handling it gracefully. makes sense why you'd avoid a universal schema too, that abstraction always leaks eventually.

1
回复
@omri_ben_shoham1 Exactly. We’d rather make the failure and retry explicit than hide a provider swap behind a universal schema and risk subtle mismatches downstream. Glad the design clicked, and thanks for digging into the details with us ❤️
0
回复

This is a useful direction. Live external data is still one of the biggest gaps for agents, especially when workflows break because one source or integration fails.

Curious how you handle source quality and freshness across different data types like search, finance, social, and e-commerce.

1
回复

@vahid_davoudi Thanks for the question, Vahid! Different data types have different notions of "quality," so we don't pretend one provider is best for everything. We continuously monitor provider health and route based on both query relevance and backend performance. If a provider starts degrading, it naturally moves down the ranking or gets replaced. Our goal is to make sure agents can consistently access the best available live source through a single interface :)

0
回复

@vahid_davoudi Quality gets two gates: vetting before a provider enters the catalog, live health stats while it's in rotation. Degrading sources sink by themselves. Freshness we pass through as is, calls hit the source live, and each data type has its own ceiling, prices in seconds, search as fresh as the crawl, social bound by what providers can access. One uniform freshness promise across all four would be marketing, not engineering.

0
回复

"No integrations, no setup" is the dream for anyone who's wired up 6 APIs by hand. The question I'd have as a builder: when a source changes or rate-limits, the auto-failover keeps the workflow running — but does the agent know it fell back to a different source, or does data quality silently shift underneath it? For anything touching finance/crypto that provenance matters a lot. Curious how you surface which source actually answered.

1
回复
@david_marko Great question, David! We agree that provenance matters, especially for finance and crypto. That's why we don't silently swap data sources underneath the agent. The agent knows which provider served the request, the provider is recorded in the transcript and console log, and we're working on adding explicit per-call fallback indicators so it's even easier to audit ☺️
0
回复

@david_marko The agent knows, because it did the falling back itself. A dying source surfaces as an explicit failure, the agent gets same capability candidates and calls a different named tool. And that's also the answer to your last question: tools are named provider first, so which source answered is literally in the name of the call sitting in the transcript. For finance and crypto that's the property you actually want, provenance baked into the call rather than bolted on as metadata. Console logs keep the full trail, and a first class fallback marker for consumers downstream of the agent is the piece still on the list.

0
回复

The auto failover detail is what catches my attention most here. keeping agent workflows from silently dying when one provider 403s or rate limits is the part that's actually painful to build yourself.

Nice to see that addressed upfront.
keep going @yanshuo

1
回复

@mohammed_messeguem The silent death part is what got us too, a 403 at step three of a twelve step workflow is its own special genre of debugging misery. If you want the gory details, someone in this thread grilled us on the exact failover behavior, candidate ranking included. Worth a scroll, it got pleasantly nerdy.

2
回复
Congrats Mogu! I run agents on Claude Code daily and the key-juggling problem is real, half my setup time is auth, not logic. My question is about runaway spend: agents loop, and a scraping loop could eat a month of credits in an afternoon. Can I set a per-task or per-agent credit cap so one bad prompt doesn’t drain the balance? That guardrail would make this an easy yes for me.
1
回复

@ridhwikvinod The runaway loop fear is earned, agents will absolutely do that to you. Two layers to the honest answer. Structurally you're prepaid, so a loop can at worst burn the credits you've loaded, that's the ceiling, there's no card quietly getting drained behind it. But no, per task or per agent caps aren't a first class feature yet. You're not the first to ask this week and the ask is completely fair, it's on the list. Free tier needs no card if you want to kick the tires meanwhile, and I'm happy to ping you here when caps land.

1
回复

@ridhwikvinod Thank you Ridhwik! Setting up different custom limits is a medium-to-high priority for us over the next month, and we hope to roll that out soon! But as Cong mentioned, we’ve already put some guardrails in place. It’s not absolutely perfect yet, but it’s more than enough to prevent most infinite loops and surprise bills.

0
回复

It's useful. How does auto-failover decide which source to switch to when one goes down?

1
回复

@dhiraj_patel5 Two things under the hood. We run automated health checks on every provider continuously, so degradation gets spotted on our side, not by your failing requests. And when a specific call does fail, the backend finds other providers with the same capability and hands back a candidate set, so the retry goes to a working equivalent that the caller chose, not a dead end.

1
回复
@dhiraj_patel5 Great question. We continuously monitor provider health based on latency, error rates, and availability. When a provider starts degrading or goes down, requests are automatically rerouted to another healthy provider with the same capability. The goal is that your agent keeps working without you having to think about it. For transparency, each response also includes which provider actually served the request and the per-call cost.
0
回复

Installing into Claude Code with one command is the right call — most MCP setups still die in config. Does failover switch sources silently, or does the agent get told the data came from a different provider?

1
回复

@wanarsan_thongklin The agent does get told. Each response includes which provider actually served it, along with the per-call cost, so nothing is hidden from the calling side. The failover decision itself is automatic, but the receipt is right there in the payload.

0
回复

@wanarsan_thongklin MCPs are incredibly powerful, but we kept seeing people spend more time configuring them than actually using them. We wanted AgentKey to be something you could install and start using with in minutes, not hours :)

0
回复

Every cool MCP server I found wanted its own key from a service with its own signup and its own minimum spend. The unbundling was exhausting. Glad someone rebundled it.

1
回复

@tammytan516 The signups and billing were the easy part to rebundle. The rest is where it gets fun: same-type providers are interchangeable so failover is automatic, the integrations are ours to maintain instead of yours, and an intent layer picks the right tool so your agent isn't guessing across the whole catalog. You see one bill, your agent sees one catalog.

0
回复

I once spent a whole weekend wiring reddit + serp + a scraping vendor into one agent, then the scraper changed its auth flow and broke everything. This is the product I wished existed that weekend.

1
回复

@cruise_chen The auth flow change three months later is the part nobody warns you about. Making that our problem instead of yours is basically the whole product. Hope the agent survived

0
回复

Super convenient and easy to use! It would be perfect if they kept the points top-up option

1
回复

@qq0018 thansk, it's still around! Check the billing page, there's an "Extra Credits" section with a top up button (needs Lite plan or above). If you're on Lite and still not seeing it, ping me

1
回复

Amazing product. Congrats on this launch!

0
回复

Any plans for a BYOK option? We already pay for a couple of these providers directly and it'd be nice to route through the same interface.

0
回复

Is there a spend cap I can set per key? Slightly nervous about an agent getting stuck in a loop and burning credits overnight.

0
回复

@crystalmei Not yet, honestly. And it's a good enough idea that it's going straight on the list. An agent looping through credits overnight is exactly the failure mode we should have a guardrail for.

0
回复

The marketplace framing is what I keep coming back to here. I build in the marketplace space myself, and the hard part is never listing supply, it's trust: when an agent pulls live data from a seller I've never vetted, how does AgentKey handle a source that's stale or quietly wrong? Ratings after the fact don't help an agent that already acted on bad data. Curious whether there's any freshness or accuracy guarantee baked in before the sale, or if it's caveat-emptor and the agent has to sanity-check.

0
回复
@chielephant Amazing question! Trust is probably the hardest part of building a marketplace. Today we're starting with a curated set of providers rather than an open marketplace, so every provider is vetted before it's added. During execution, we continuously monitor provider health (latency, error rates, availability), and if one degrades it naturally falls down the ranking or out of rotation. What we don't claim today is a universal "accuracy guarantee" across every data source; that's still something the agent should reason about. But over time, we want to use the feedback we see across millions of calls to surface quality signals, not just uptime ☺️
0
回复

@chielephant You've put your finger on the reason the marketplace isn't open yet. Today every source in the catalog got there through us: providers are vetted before they're listed, so there's no seller in there we haven't looked at. That covers entry. In rotation, health stats catch the operational failures, a source that starts erroring or lagging sinks in ranking on its own. What I won't claim is an accuracy guarantee on the values themselves. Quietly wrong is the hardest failure in this business, and anyone selling a guarantee against it is being optimistic. The practical ex ante defense is corroboration: with equivalents sitting behind the same key at per call prices, having the agent read a second source for anything high stakes is cheap, and that's what careful builders here already do. Opening self serve supply before that trust layer is productized would be doing it backwards, which is why curation comes first.

0
回复

Super cool! Is it flexible enough to bring in data from specific sources that I already have access to for eg. as a student I used to have access to pitchbook but couldn't use it in the context of an agent because of integration limitations even if I have a subscription.

0
回复
@margharitha Good question :) Today, AgentKey works through the AgentKey marketplace rather than plugging into your existing subscriptions like PitchBook. The value comes from managing the provider pool end-to-end, which enables things like health monitoring, QoS routing, and automatic failover. If you already have access to a proprietary data source, the recommended setup today is to run that integration alongside AgentKey in the same agent. We've also had several people ask about bringing their own provider keys, and it's something we're actively exploring for the future.
1
回复

@margharitha Not today. The frustration is legit though, you pay for access and the subscription assumes a human reader. Public pages the catalog's scraping tools can cover, but a login gated licensed database wants an official integration rather than a workaround. That's where the marketplace direction points: sources like that onboarded through their own channels, agent ready.

0
回复

Really interesting approach. One question: if I already have my own API keys for some providers, can I use those with AgentKey, or does everything go through the AgentKey account?

0
回复

@nayan_joshi Honestly, we hadn't thought about that yet, but that's a brilliant point! We might actually support this down the road. maybe letting you plug in your own keys in the dashboard, or even just telling the Agent via natural language. That way, you wouldn't be billed for using your own keys. Appreciate the feedback!

0
回复

@nayan_joshi All through the agentkey account today, and honestly that may stay the answer. The value is in the pool being managed end to end: health stats, QoS shaping and failover only work on keys we operate. Your existing keys don't go to waste though. They can sit right next to AgentKey in the same agent, direct connections for the providers you've already invested in, us for everything else.

0
回复
#3
AI Media Buyer By Creatify
Your ads, managed by AI that gets smarter daily.
328
一句话介绍:AI Media Buyer通过连接Meta、Google、TikTok等广告账户,自动审计广告花费、识别浪费点、生成新创意并执行优化,让广告投手告别多平台手动操作和数据猜谜。
Social Media Marketing Advertising
AI广告投放代理 广告账户审计 创意自动生成 跨平台广告优化 付费投放自动化 广告ROI优化 营销效率工具 数据驱动决策 MCP协议 广告预算管理
用户评论摘要:用户关心:自动化是否能限制预算和创意测试范围,以免“烧钱”;平台归因数据与真实收入(如Stripe/CRM)不匹配问题;创意在Meta与TikTok间的格式自适应;小账户是否适用;是否支持多客户账户隔离;以及系统如何判定“胜出素材”再放量。创始人和团队回应:不自动执行花费,需用户审批;打通Stripe/CRM数据校正;创意按平台调整格式;支持小账户;账户数据隔离;胜负判定以真实收入信号为准。
AI 锐评

Creatify的AI Media Buyer是一个典型的“技术缝合怪”升级版,它的聪明之处不在于发明了新的AI能力,而在于精准切入了数字广告行业最痛的“分析-执行”断裂带。

**价值在于闭环,而非智能。** 市面上已有大量AI广告分析工具(如披露“哪里花钱多”),也有创意生成工具(如自动做视频)。但这两个环节一直是分离的:投手看完分析报告,还要手动去创作工具里调素材、再回广告平台排队上线。Creatify将“审计→识别→生成→投放”连成一条自动Pipeline,并让AI通过Chat交互提示执行,这才是它真正的护城河——省去了人类在多个工具间“搬运”的环节。正如评论中用户所说,“闭环”是最大的游戏规则改变者。

**警惕“代理幻觉”与信任门槛。** 产品的弱项在于,它把审计权和建议权交给了AI,却把执行权和责任压在用户身上。创始团队强调“所有动作需审批”,本质上是承认AI目前无法承受“自主花错钱”的后果。这决定了它不是一个“自动化代理”,而是一个“高级智能副驾”。虽然这降低了初期风险,但也限制了其增值空间——如果投手每项操作仍要手动确认,那效率提升的边际效益会递减。真正的挑战是,当AI连续推荐正确10次后,用户是否敢于放开“无审批”模式?这取决于创意生成与预算调度的可靠性,以及平台方(Meta/TikTok)API的波动性。

**数据整合是面照妖镜。** 产品支持接入Stripe/CRM是神来之笔。绝大多数广告主苦于“Meta归因漂亮但收入不匹配”,Creatify用支付端真实数据校正广告决策,本质上是在做“反欺诈”和“归因清洗”。这项能力远比让AI看广告面板报表更有商业价值,也是它能在争议中建立信任的基石。

**致命的盲区:规模与个性化的矛盾。** 目前产品逻辑依赖历史表现数据“赢家再生”,这天然偏向保守——只优化已被验证的模式,难以探索突破性的创意方向。对于大预算、追求爆款的品牌,这种迭代可能沦为“内卷优化”。同时,跨平台策略(如Meta的强社交推荐 vs TikTok的强算法推流)如何通过一个Agent统一学习,逻辑上存在冲突,用户的质疑“赢家素材在TikTok失效”正是对此的验证。

结论:这是个方向正确、执行扎实但尚需精进的产品。它最适合“中等预算、多平台、人少活多”的成长型团队作为效率工具,但距离“让AI完全接管广告预算”的梦想,至少还差一次“自主犯错权”的进化。

查看原始信息
AI Media Buyer By Creatify
Every media buyer knows the ritual: five dashboards, three hours of reports, still guessing what to do next. Creatify AI Media Buyer connects to your Meta, Google, AppLovin and TikTok ad accounts and does what a human buyer does audits campaigns, finds spend that's quietly bleeding, spots what's scaling, and acts on it. It generates new creatives from your actual winners and launches them, all through chat. And it remembers your account history, so its recommendations compound over time.

Hey Product Hunt, I'm Yinan, founder of Creatify.

Quick backstory: we've spent 3 years building Creatify. Started with URL to video, then avatars, Ad Clone, and a full creative agent. 3M+ users have used the platform.

But one thing kept bothering me. Our users would make great ads, launch them, then go back to staring at dashboards for hours trying to figure out what was working. The creative side was solved. The media buying side was still manual, scattered, and slow.

So we built AI Media Buyer an agent that plugs into your ad accounts and actually does the work.

How it runs:

  1. Connects to your Meta, Google, and TikTok accounts (OpenAI ad accounts too now 🤫). Reads every campaign, finds what's scaling and what's quietly bleeding spend.

  2. It doesn't just alert you. It acts recommends what to cut, what to scale, and can generate new creatives from your winners and launch them in one loop.

  3. It remembers your account and past conversations. Recommendations compound the more you use it.

  4. Cross-references your ad data with Stripe and CRM, so you see real numbers, not just Meta's attribution.

The part I'm most proud of: this is the only AI media buyer with a built in creative engine. Most tools stop at "here's what happened." Ours finds a winning hook, makes variations, and launches them. No other tool does that.

One early user found a campaign they'd paused was actually producing their highest-value buyers Meta was undercounting it. The agent caught it.

I'll be in the comments all day. What's the most painful part of managing your ad accounts right now?

18
回复

@nyn531 What always burns me when I hand paid spend to an automated system is the learning phase, where it quietly torches budget figuring out what converts. Can I cap daily spend and lock which creatives it's allowed to test, or does it need free rein to get smart? Curious how much manual override you left in for the operator.

4
回复
@nyn531 The creative + media buying loop in one agent is a game changer. Closing the gap between analysis and execution is huge.
0
回复

@nyn531 Impressive launch! 🚀 AI Media Buyer solves a real pain point by connecting creative performance with actual ad optimization and revenue data. The ability to analyze, scale winners, and launch new creatives automatically is a huge time saver for marketers. Congrats on the release! 👏

0
回复

Hey PH 👋 Chaz here, CTO/co-founder at Creatify.

Wiring an LLM to ad APIs over MCP is a weekend project now. Making the agent good is the hard part, and that's where the work went.

Three things that ate my time: getting it to genuinely understand account structure — hierarchies, budget inheritance, what each knob actually does, because get that wrong and every downstream call is confident nonsense; wiring it into our creative agent so the loop actually closes (spotting a dead creative is easy, being able to regenerate it in the same system is the part most tools can't do); and getting it to shut up, so it hands you the call and the reason instead of six paragraphs.

If you've burned real budget on ads, come try to break it. Most interested in where it misreads an account. 🙏

9
回复

@chaz_ Interesting product! I'm also building in the productivity space with FocusQuest. I’m a huge fan of exploring new ways to stay focused and fight digital addiction. Keep up the great work!

0
回复

curious what happens when a winning hook on meta just flops on ticktok, does the creative engine adjust format or just reuse it as is"

5
回复

@wyatt_cameron Good question. The agent treats them as separate signals a hook winning on Meta doesn't get blindly pushed to TikTok, since it's reading performance per platform. When it generates variations from a winner, [VERIFY: it adapts format/style for the target platform aspect ratio, pacing, hook style] rather than reusing the exact asset. And if the TikTok version flops, that's data too it'll flag it the same way it catches anything bleeding spend, and iterate from what TikTok is actually responding to.

0
回复

congrats on the superb launch! Curious how it decides something is actually a winner before it scales budget into it. What window and what signal does the agent trust before it commits spend?

4
回复

@artstavenka1 Thanks Art Stavenka 🙏 Two parts: it doesn't trust platform numbers alone, winners get verified against what actually hit Stripe/CRM, since Meta's 7-day click and real revenue often disagree. And it never commits spend on its own it shows the signal and reasoning, recommends the scale, you approve. The trust call stays with you, not a buried threshold.

1
回复

how does this handle attribution windows? meta's 7-day click vs what stripe actually shows never matches for us

4
回复

@elle_go Yeah, this mismatch is basically why the Stripe/CRM connection exists. Instead of trusting Meta's 7-day click as truth, the agent pulls what actually hit your revenue and reads performance against that. That's how the paused campaign story in the founder comment happened Meta's window was undercounting a campaign that Stripe showed was producing the highest value buyers. So recommendations get made off real numbers, not platform reported ones.

1
回复

As a Paid Ads Growth Manager, I manage growth across Google Ads, Meta, TikTok, and other channels. Surprisingly, most of my time isn’t spent launching campaigns—it’s spent analyzing data, comparing performance across platforms, identifying opportunities, and making hundreds of optimization decisions every week.

What impressed me most about AI Media Buyer is that it goes far beyond dashboards. It helps turn data into actionable decisions. From performance analysis and strategy recommendations to creative generation and optimization, it feels like a true AI co-worker rather than just another AI tool.

I’ve been fortunate to see this product evolve from the early days, helping refine the ads strategies behind it. Today, the quality of its recommendations is genuinely impressive, and it’s already become part of our internal workflow.

I truly believe AI Media Buyer is changing how paid advertising gets done. The future isn’t AI replacing marketers—it’s AI and marketers making better decisions together.

Huge congratulations to the Creatify team on the launch! 🚀

4
回复

"strength is clearly the closed loop between finding a dead creative and regenerating one in the same system, weakness is trusting one agent to touch spend across four platforms at once without a human checking first, that's a lot of trust to earn early

3
回复

@ian_maxwell2 Fair concern, and it's exactly why nothing touches spend without approval. The agent audits, recommends, and preps the action - cut this, scale that, launch these variations but you approve before anything executes. The closed loop is the automated part; spend changes keep a human on the trigger. Trust it more over time? Your call not a default.

0
回复

"does this work ok for smaller accounts or mainly built for bigger spend.

3
回复

@paige_lauren1 Works for smaller accounts too, some of the most useful catches happen there, since wasted spend hurts way more on a small budget. The agent reads whatever's in the account, whether that's 2 campaigns or 200. Trial doesn't need a card, so easy to test on your own account and see what it flags. What platform are you running on?

0
回复

congrats. quick question: how do you balance automation with account-specific strategy? For example, can I set guardrails like target ROAS, audience exclusions, or preferred creative styles so the AI's actions align with our brand and long-term goals?

2
回复

@swati_paliwal Thanks! Yes, you can set constraints like target ROAS and exclusions, and the agent works within them when it recommends. On creative style, it learns from your account: it generates from your actual winners, so brand direction comes from what's already performing. And nothing executes without your approval, so strategy alignment gets checked on every action, not just at setup.

4
回复

@swati_paliwal Interesting product! I'm also building in the productivity space with FocusQuest. I’m a huge fan of exploring new ways to stay focused and fight digital addiction. Keep up the great work!

0
回复

Congrats on the launch.This hits a very real pain point. The jump from “reporting what happened” to actually finding wasted spend and taking action is where most ad tools fall short. Curious how much control buyers keep before changes go live, especially around launching new creatives or shifting budget.

1
回复

@vahid_davoudi Full control on both new creatives and budget shifts are prepped by the agent but launch only after you approve. It does the analysis, builds the recommendation with its reasoning, and queues the action; you're the one who fires it. So the "taking action" part means the work is done for you, not done without you

0
回复

@vahid_davoudi It's a copilot experience. The agent will ask for your approval before making budget related actions to your ad account.

1
回复

How long is the setup process to try it out?

1
回复

@nick_jones33 Under 2 minutes, OAuth into your ad account, and the agent starts its first audit right away. Fastest way to answer whether it's useful is just connecting and seeing what it flags. 🙌

0
回复

As Creatify’s co-founder and Chief Scientist, I’m especially excited about how AI Media Buyer closes the loop between creative generation and campaign performance. It doesn’t just analyze what happened—it identifies winning patterns, generates new creative variations, and helps launch the next round of tests.

This is a big step toward the system we’ve always wanted to build: an AI agent that continuously learns from real performance data and turns those insights into better ads. Excited to hear what the Product Hunt community thinks!

1
回复

Congrats on the launch! If someone's managing ad accounts for multiple clients, does the agent keep learnings and account history separate per client, or is it more built for a single in-house account right now?

1
回复

@irahimiam Thanks Arash! Learnings stay separate per connected account each client's history, patterns, and context are scoped to that account, so recommendations for Client A never leak from Client B's data. The multi client agency setup is exactly a use case we built toward. Would love to hear how many accounts you're juggling if you test it.

0
回复

Wow Yinan! Love what you're doing here. Ads are evolving and you're making it so easy and powerful. I'm sure many founders gonna take the most of Creatify. All the best here!

1
回复

@german_merlo1 Appreciate it! We are just getting started. Please give a try and let me know for any feedback!

1
回复

Does it work if I’m running like 90% of spend on Meta only, or does it need multiple platforms connected to be useful?

1
回复

@marianne_guerrero Works fine Meta only, most of what the agent does (auditing campaigns, catching bleeding spend, generating creatives from winners, scaling calls) happens within a single platform. Multi-platform just adds cross channel visibility on top; it's not a requirement. If 90% of your spend is Meta, that's 90% of where the value is anyway. Connect it and see what the audit flags 🙌

0
回复

Congratulations on the launch, Yinan and team! 🚀 This feels like a real step beyond another analytics dashboard. Media buyers spend way too much time jumping between platforms and piecing together reports manually. The idea of an AI that actually understands account history and helps identify what's working is incredibly compelling. Curious to see how much time and performance uplift early users are seeing. Wishing you an amazing launch day! 🎉

1
回复

@suryansh_tiwari2 Thanks Suryansh, Honest answer on uplift: too early to quote a real average, and we'd rather not make one up. What early users report most is reporting hours collapsing the audit does in minutes what used to take a morning. Real numbers once we can say them with a straight face. Good luck with EverTutor!

0
回复

This is really cool! As someone who has ventured into Google Ads for my personal brand recently, I know the pain of creating creatives. This is the kind of workflow I'm thinking of.

1
回复

@heyitsirenechan Thanks Irene! And yeah the creative side is usually where solo brands stall, since you're the strategist, media buyer, and production team all at once. That's exactly the workflow this collapses. If you connect your Google Ads account during the trial, curious what the audit surfaces on a newer account like yours 🙌

0
回复

It looks really useful. How has it been working for people who create videos regularly? I'm wondering if the quality stays consistent across different types of content.

1
回复

@hamza_afzal_butt Thanks Hamza! Consistency is mostly a model selection problem, different content types need different models, and the pipeline picks per scene rather than forcing everything through one generator. That's a big part of why output holds up across product demos vs. UGC style vs talking head formats. On the Media Buyer side there's also a feedback angle: it generates from your actual winners, so new creatives inherit what's already proven on your account. That said, the trial's the honest answer connect it and see what it makes from your product. 🚀

1
回复

Congrats on the launch!🚀 Automating both ad creation and media buying is an interesting direction. Curious......how much control do users have over the AI's campaign decisions?

1
回复

@worksforme Thanks! Full control, the agent audits and recommends, but every campaign action (cutting, scaling, launching creatives) goes through your approval before it executes. Think of it as an analyst that preps the decision and shows its reasoning; you stay on the trigger. It also remembers preferences you give it in chat, so the recommendations bend toward how you actually run your account.

1
回复

This is a huge step forward. Love the idea of an AI that doesn't just report on performance but actually takes action and learns from account history. Excited to see where this goes. 🚀

1
回复

@kyle_chua Appreciate it 🙏 The learning over time piece is the part we're most excited to see compound with real accounts, give the trial a spin if you're curious what it catches on yours.

0
回复

how many conversions does a creative need before the engine treats it as a "winner"?

0
回复

Awesome product!

0
回复

Solo founder here, I do all my marketing myself. What's the minimum monthly ad budget where this starts to make sense ?

0
回复

The part I'd want to see is whether people are comfortable letting an AI make changes to campaigns instead of just recommending them. How much control does the user have before the AI actually launches or changes a campaign?

0
回复

@nyn531 @gourav_chhabra2 verifying winners against Stripe instead of Meta's attribution is the smart part here. Question from the operator side: when a winner starts to decay, can it tell creative fatigue from audience saturation? Those need opposite responses and most tools treat them the same. And does it touch the audience side at all, or only creative and budget?

0
回复

curious about the approval flow can I set thresholds so small budget changes auto-apply but big ones need sign off?

0
回复

The "staring at dashboards for hours trying to figure out what worked" ritual is painfully real. The part I'd need to trust before handing over spend: when it recommends cutting or scaling, does it surface the reasoning, or is it more "trust me"? For media buyers the fear isn't automation — it's an agent quietly killing a campaign that was about to turn. How much of the "why" does it show?

0
回复

@david_marko The reasoning is the whole product, honestly every recommendation shows the "why": what it read, what it found, what it suggests. Nothing gets killed quietly; you approve every cut. And the flip side: the founder note story is the agent catching a campaign a human had wrongly paused it was producing the highest value buyers. The reasoning layer cuts both ways.

0
回复

An agent that actually runs the buying, not just drafts the creative, is where this gets interesting. The hard part is rarely generating variants, it is killing a losing ad fast enough for it to matter. I wonder how much control it hands back on budget guardrails before it starts spending, because that is usually the line between a helper and something people are scared to turn on.

0
回复

@liana_preston "Killing a losing ad fast enough for it to matter" that's exactly the job. The detection runs without you: continuous performance reads, verified against actual revenue, so losers get flagged same-day instead of at your Monday report pull. On guardrails approval first on everything. The agent preps the kill or budget shift with its reasoning, you approve, it executes. The scary autonomous version isn't the starting point; the speed win is that detection and prep happen without you, the decision stays yours.

0
回复

AI Media Buyer finally closes the loop for performance marketers making it an end-toend platform that studies your product, researches competitors, orchestrates a team of agents to build creatives, uploads assets directly to ad platforms, and manages the accounts.

0
回复

"spots what's scaling, and acts on it" is the part I'd want a kill switch for. does it auto-shift budget between campaigns on its own, or does it draft the move and wait for you to approve before touching spend?

0
回复

@sabber_ahamed it drafts the move and waits. Nothing touches spend, budgets, or campaign status without your approval; the agent preps the action with its reasoning and you sign off. So the kill switch you're describing is effectively the default state: it can't act on spend unilaterally. The "acts on it" part is that it does the full prep analysis, recommendation, ready to execute change. instead of just alerting you and leaving the work.

0
回复
#4
Loomal
Monetize any MCP server in 5 minutes with no % skim.
292
一句话介绍:Loomal通过一行代码集成,让API、MCP服务器或数字商品拥有一个AI代理可自动发现并支付(USDC结算,约2秒)的“代理友好型”支付墙,解决了AI代理有钱包但无处消费的痛点。
Payments Developer Tools Artificial Intelligence
AI代理支付 MCP服务器变现 USDC结算 数字商品支付 自动化收入 代理经济 无抽成支付 零代码集成 Shopify插件 去中心化商业
用户评论摘要:用户关注点包括:代理如何发现API(有机器可读的Index);非加密用户的钱包设置是否简单(自动创建无感);防欺诈与身份审计(链上签名与收据);重试与幂等性问题(协议级防重放);与Stripe的差异(专注机器对机器与无抽成);以及代理身份被入侵后的撤销机制(独立身份可单独吊销)。
AI 锐评

Loomal切中的是一个真实且日益紧迫的痛点:AI代理拥有支付能力,但互联网基础设施依旧为人类设计。其核心价值不在于“支付”,而在于“为机器重塑商业层”。通过放弃信用卡与订阅模型,采用USDC即时结算与无抽成模式,它在经济上彻底颠覆了传统平台税逻辑——这正是Stripe等巨头因沉没成本而难以跟进的方向。但产品的真正胜负手并非技术,而是网络效应。Loomal能否成功,取决于其“发现索引”能否成为代理默认的“应用商店”。目前,买家发现仍部分依赖人工复制URL,这暴露了冷启动难题。此外,仅靠“无抽成”吸引卖家是脆弱的,一旦规模化,平台必须证明其聚合的代理流量能带来远超手动分发的订单。评论中关于身份、审计和失败重试的讨论,指出了关键:在机器交易中,信任与可追溯性比支付本身更生死攸关。Loomal若仅作为支付管道,终将被API网关或区块链原生协议替代。其护城河必须建立在“代理身份+可信交易数据+去中心化声誉系统”三位一体的闭环上。从商业逻辑看,允许代理用“失败的成本”来自动淘汰劣质服务,比人类写差评更有效率。但这也意味着,卖家实际上是在为一个尚不存在的“代理消费者市场”提前布局。这是极客的浪漫,也是资本的赌注。一句话:Loomal卖的不是支付,而是AI世界的商业入场券——但它需要证明自己不只是卖票,还能真正把人潮引进来。

查看原始信息
Loomal
Loomal lets you charge for what you sell online — API calls, tools, digital products, or your whole store. One line of code (or a Shopify/WooCommerce plugin) adds an agent-ready paywall: AI agents pay you in USDC, settled in about 2 seconds, and you keep 100% of your revenue — no percentage cut, ever. Free to start, no card; flat monthly plans as you grow. Every paid listing appears on the Loomal Index, where agents discover and pay. Launch offer: first 500 sellers get 1,000 transactions free.

👋 Hey Product Hunt!

I'm Danny, maker of Loomal.

🤖 AI agents are starting to buy things. They research, compare, and complete purchases on their own.

⚠️ But here's the problem. Almost nothing online can sell to them.

Stores and APIs are built for humans. Browsers. Credit cards. Checkout forms.

Agents don't have those. They have wallets. 👛

So we have this strange moment:

millions of agents with spending power, and an internet that can't take their money. 💸

That's why I built Loomal. 🚀

Loomal makes anything you sell agent-ready. Agents discover it, pay for it, and use it — no human in the loop.

⚡ What makes Loomal different?

👉 One line of code for your API or MCP server. No re-architecture.
👉 Agents pay in USDC. Settlement lands in ~2 seconds.
👉 You keep 100% of your revenue. We never take a cut.
👉 Every paid listing goes on the Loomal Index, where agents discover and pay for services.

🛍️ For Sellers
List what you already sell.
An API.
A SaaS tool.
Digital goods.

✅ One-line integration
✅ Instant USDC settlement
✅ Zero revenue share
✅ Discoverable by agents on the Loomal Index

🤖 For Agent Builders
Give your agents services they can actually pay for.
❌ No scraping.
❌ No stolen credit cards.
❌ No human checkout.

🎯 Who is Loomal for?
🛠️ API and MCP server builders 🤖 Agent developers 💾 Anyone selling digital services who wants to be ready when agents come shopping

🎁 PH-only offer: first 500 sellers get 1,000 free transactions. Enough to validate real agent demand before you pay us anything. Free to start, no card. 💳❌

💬 Two questions: what do you sell that agents should buy? And what's missing before you'd list it?

🔗 Live demo at https://loomal.ai — here all day.

Thanks for checking us out! 🙌

8
回复

@dannyheng What's the biggest blocker keeping you from listing on Loomal right now; technical, billing, compliance, or something else?

2
回复

@dannyheng Congrats to the Loomal team! Happy to hunt it today. You're not just enabling payments, you’re helping create an entirely new commerce layer for AI agents. 💙

1
回复

@dannyheng Congrats on the launch! This is incredibly cool. I'm building my own personal agents as a hobby (openclaw calendar trackers, productivity managers etc.) and always thought the next step is agents having their own wallet and being able to transact with each other.

One particular hobby project I'm working on now is an android headunit agent that reads your car OBD data and keeps logs and alerts you when critical codes appear. It'd be so cool if the agent could schedule mechanic appointments and even pre pay for them according to the specific fault code that appears. Definitely will experiment with the SDK

0
回复

@dannyheng Everyone's asking about payments, but the part I don't get is discovery. Say I list my API on the Index today — how does an agent actually find it? Is there something agents query programmatically, or are we still waiting for a human to paste a URL into a prompt?

1
回复

@aparna_rajesh This is the underrated half of the product, glad someone asked 😄

The Index is machine-readable end to end — agents query it programmatically: search by capability, compare prices, read the schema, and pay, all in one flow with no human pasting URLs. Discovery, evaluation, and purchase are the same session.

Today, plenty of traffic still starts the old way — a developer finds a listing and wires it into their agent. Both paths work, but the programmatic one is the future we're building for: your listing isn't a webpage with a "docs" link, it's a structured record an agent can act on the moment it decides it needs what you sell.

That's the real answer to "why list now": you're not just adding a payment method, you're becoming findable by buyers that search in milliseconds and never sleep.

0
回复

Congrats on the launch! This is incredibly cool. I'm building my own personal agents as a hobby (openclaw calendar trackers, productivity managers etc.) and always thought the next step is agents having their own wallet and being able to transact with each other.

One particular hobby project I'm working on now is an android headunit agent that reads your car OBD data and keeps logs and alerts you when critical codes appear. It'd be so cool if the agent could schedule mechanic appointments and even pre pay for them according to the specific fault code that appears. Definitely will experiment with the SDK!

1
回复

@kevin_win This is exactly the kind of thing we daydreamed about while building. The OBD agent is a great example because it's the full loop: detect fault, find service, pay, all with zero human in the mood to deal with it 😄

The honest gap you'll hit: your agent can pay today, but the mechanic side needs an agent-payable endpoint too. That's the chicken and egg the Index exists to solve. Even a simple booking API with a deposit endpoint would make your demo work end to end.

Please do experiment with the SDK, and when the headunit agent makes its first payment, I want to see the video. You're in the founding 500 if you list anything. What's your stack on the agent side?

0
回复

for sellers who aren't crypto native, is the wallet setup actually 5 minute thing too, or is that the part that quietly takes longer than the sdk integration itself.

1
回复

@isabella_hayes4 Fair — that's usually exactly where these things quietly fall apart 😄


Honest answer: there is no wallet setup. When you create a seller identity, we provision a non-custodial wallet for it automatically — no browser extension, no seed phrase to write on paper, no buying ETH for gas.


Agents pay in, USDC lands in your wallet, and your dashboard shows a balance in dollars. The only moment crypto-nativeness could matter is withdrawing — and that's a button, not a ritual.

So the SDK integration really is the long pole, and it's one line. The wallet part is the bit we were most determined to make boring.

0
回复

par cell pricing sounds fair until every seller on the index races to undercut each other on price, same thing that happened with app store pricing wars.

1
回复

@hudson_reid commodity endpoints will compress, no point pretending otherwise. But two differences from the App Store: there's no 30% platform cut here forcing everyone to $0.99, and agents don't impulse-buy — they optimize for task completion. A cheap endpoint that fails costs the agent's owner more than the price gap, and that shows up in repeat-purchase data fast.

0
回复

stripe is clearly moving into agents payments too, curious what makes loomal a better bet than waiting for them to ship something similar.

1
回复

@holden_chase Honestly, Stripe moving in validates the space — but we're not really racing them on the same track.

Stripe's agent work is about agents buying from human commerce: checkouts, cards, merchants. Card rails are brilliant for a $40 cart and hopeless for a $0.01 tool call — the fixed fee alone eats the transaction. Our whole bet is machine-to-machine: agents paying APIs and other agents per call, settling in ~2 seconds, no % skim. That's economically impossible to retrofit onto card infrastructure — it needs different rails, which is why we built on x402 instead.


The other piece Stripe doesn't touch: agent identity. When a machine pays a machine, "who authorized this?" matters more than the payment itself. Every agent on Loomal has its own verifiable identity, scoped permissions, and signed receipts for every call — payments and accountability in one stack.

1
回复

@holden_chase Stripe don't do discovery for builders. Their agentic commerce stack points at retail checkout through the big assistants, not a neutral index where agents find indie API and MCP sellers. That index is our bet — plus flat plans, no cut of your revenue. Big merchant on Stripe? Use Stripe. Builder who wants agents to find and pay you? That's us.

0
回复

good stuff! from the buyers' perspective: if my AI agent makes a mistake, how do I prove what it did and who authorized it? or there's no chance?

1
回复

@marcin_uchacz1 There's a chance — it's actually two layers.

On Loomal: every payment produces a signed receipt — which agent paid, which endpoint, amount, timestamp. So for transactions, the record exists by default.

"What did it do and who authorized it" beyond payments is an identity problem, and it's exactly why we built Mailgent (launched here last week): each agent gets its own cryptographic identity, actions are signed against it, and permissions are scoped — so you can show which agent did what, under whose authority, with proof.

0
回复

@marcin_uchacz1 There's very much a chance — this is honestly the whole reason we glued identity to payments.

Every agent on Loomal has its own verifiable identity with its own keys — it's never "someone with the company card," it's that specific agent. Every payment it makes settles on-chain (public tx) and comes with a signed receipt binding the agent, the recipient, the amount, and the exact resource it paid for.


So when your agent does something dumb, you can reconstruct the whole story: which agent, what it paid, to whom, for what, and when — and verify every signature independently, without trusting us. You scope what each agent is allowed to do up front, and the receipts prove what it actually did.


Blaming the intern has never been this cryptographically rigorous.

0
回复

no % skim plus 2 second settlement is a real edge over the platform fee model. what stops a misconfigured agent from retrying a failed call and paying you multiple times for the same request, is idempotency on the caller side or yours?

1
回复

@sabber_ahamed Loomal verifies each signed payment authorization and returns a signed receipt after settlement. We’re also designing the retry flow so a failed request doesn’t accidentally result in duplicate charges, but we don’t want to overstate the current guarantees around idempotency yet. For now, callers should use sensible retry and request-deduplication logic.

0
回复

@sabber_ahamed Great question — the replay safety is protocol-level, so neither side has to be careful 😄

Every payment is a single-use signed authorization — once it settles, it's spent. A misconfigured agent retrying the same request just re-sends the same authorization, and it simply can't settle twice. And if the call fails before settlement, no money moved at all.


Where we go beyond vanilla x402: we verify before we ever settle (amount and recipient must match what was actually signed), and every settled call gets a signed receipt — so both sides have cryptographic proof of exactly what was paid, once. Stock x402 gives you the rail; we added the paper trail.

0
回复

I Shipped an MCP server myself recently. Getting every tool call and edge case right before it's client-facing takes real discipline. Respect for shipping 18 tools this clean.

Since you're MCP-native across LangChain, CrewAI, Claude, etc. Did you build against one runtime first and adapt, or design for all of them from day one?

1
回复

@benjouss Thanks — and congrats on shipping yours, you know exactly how much invisible work "clean" hides 😄

Honest answer: neither. We built protocol-first. The MCP layer is deliberately thin — each tool is basically a shim: typed schema in, one API call, structured result out. All the real edge cases (auth, payment state, error semantics) live behind the API, so there was never per-runtime code to adapt.

We did test against Claude first since it's the strictest client — sloppy schemas get exposed immediately. Once it was clean there, LangChain and CrewAI mostly came free via their MCP adapters.

The actual "adapting" was never the tool calls — it was tuning descriptions and error messages until every model behaved. Protocol-first by design, Claude-first by discipline.

0
回复

@benjouss Watching from the business side, the "tuning descriptions and error messages until every model behaved" part was the surprise for me. Turns out in agent land your docs and error strings basically are your UI. We'd rewrite one tool description and watch success rates move the next day. Benjamin, since you shipped one yourself, curious if you saw the same thing: which mattered more for you, schema strictness or the wording agents actually read?

0
回复

The Shopify and WooCommerce plugins should help bring non-technical sellers into the agent economy much faster. :)

1
回复

@roopreddy Thats why we think the agent economy is going to explode! Native Shopify and WooCommerce integrations should let sellers expose what they already offer to agents without needing to understand APIs, MCP, or crypto infrastructure first.

0
回复

@roopreddy This is the part that changes the scale of the whole thing. Developers listing APIs is the beachhead, but the long tail of the agent economy is millions of existing stores where the seller will never read an API doc — and shouldn't have to. A plugin turns "agent-ready" from an engineering project into a checkbox in a dashboard they already use.

The day an agent can buy from a regular WooCommerce store as easily as from a purpose-built API, it stops being a developer economy and starts being the economy

0
回复

I am wondering how fraud prevention works once thousands of autonomous agents start making purchases simultaneously?

1
回复
@nuseir_yassin1 Thanks Nuseir! Fraud actually looks different in agent commerce — some of it gets easier: Stolen cards disappear. Agents pay from their own USDC wallets under spend mandates. No card numbers to steal, no chargebacks. Payment fraud’s biggest vector just isn’t there. Every agent has an identity — and a wallet with history. Payments are signed by the agent’s keys, and wallet credibility is checkable on-chain: age, transaction history, behavior patterns. A brand-new wallet suddenly firing thousands of purchases looks very different from an established one — that’s a fraud signal humans-with-cards never gave us. Sellers are vetted too. Verified identity, on-chain transaction history, and reviews from real paid usage on the Index. Agents check a seller’s actual track record before spending — reviews that can’t be faked because they’re settled transactions.
1
回复

@nuseir_yassin1 The scale part of your question is actually the interesting bit, Nuseir. Thousands of agents buying simultaneously sounds scary until you remember every one of them is legible. Signed identity, wallet history, spend caps. Compare that to card fraud where the whole game is guessing whether a human is who they claim. Volume was the enemy in card fraud because review was manual. Here the checks are per transaction and automatic, so scale doesn't dilute them. Honestly the anonymous human with a stolen card was always the harder problem.

0
回复

Congrats. The one-line integration is probably what caught my attention first. Adoption usually comes down to reducing setup friction.

1
回复

@himani_sah1 Thank you! That’s exactly what we’re aiming for—making adoption feel effortless. The one-line integration removes the usual setup overhead so teams can start seeing value almost immediately. Really appreciate your support!

0
回复

That's interesting. Do agents handle failed USDC transactions automatically, or does the seller need to retry?

1
回复

@dhiraj_patel5 The agent handles the retry, not the seller. Loomal returns the failure reason, and the agent can retry automatically for transient issues as long as the spend mandate is still valid. For issues like insufficient balance or an expired mandate, the buyer agent has to resolve it before retrying. The seller should never need to manually re-initiate the charge or risk creating a duplicate payment.

1
回复

Congrats on the launch! Making MCP monetization simple is a great idea. As more agents rely on MCP servers, how are you thinking about reliability when a server changes behavior or returns unexpected responses?

1
回复

@amjad_shaik Per-call pricing is the first line of defense. A server that changes behavior or degrades burns an agent for cents, not a monthly subscription — the agent just stops paying and routes elsewhere. Bad servers lose revenue immediately.

We don't validate responses or SLA-check servers today. Longer term, the Index builds machine-readable reputation from settled transactions — uptime, consistency, repeat-purchase rate. Reviews that can't be faked, because they're actual paid usage.

0
回复

Haha this framing of giving an agent its own identity instead of duct taping it onto a human's is a clean way to describe a problem that's been quietly obvious for a while (agents running on borrowed Gmail passwords and unscoped API keys with no audit trail).

Wondering if an agent's vault or inbox gets compromised, is there a way to revoke just that agent's identity without breaking every other agent sharing the same account?

1
回复

@uddipta You've actually wandered into our sister product 😄 Loomal handles the payments side; the identity/inbox/vault layer you're describing is Mailgent (mailgent.dev) — same team, built to work together.

To answer directly: yes, that's the whole point of giving each agent its own identity instead of a shared account. Every agent gets its own DID and its own Ed25519 keypair — nothing is shared. So if one agent's vault or inbox is compromised, you revoke that agent's identity and keys, and every other agent keeps running untouched. No blast radius, and the audit trail shows exactly what the compromised agent did before revocation.

That's exactly the failure mode of the "borrowed Gmail password" setup — one leak takes down everything and you can't even tell what happened.

Happy to go deeper on the Mailgent side if useful, but didn't want to hijack the Loomal thread 😅 On the Loomal side: agents pay under scoped spend mandates, so a compromised agent can't drain a wallet either — you revoke the mandate and it's done.

0
回复

The MCP server monetization focus is neat. One thing I’m wondering: when you say “in 5 minutes,” is Loomal mostly handling payments/access control around an existing MCP server, or does it also help with packaging, hosted endpoints, or user management? The no % skim detail makes the business model feel builder-friendly, so I’d be curious what parts are included in the basic setup.

1
回复

@mia_qiao The 5 minutes is payments and access around your existing server: install the SDK, wrap the endpoints you want to charge with requirePayment(), set prices. No hosting, no packaging — your server stays where it is.

Basic setup includes: the paywall, your listing on the Loomal Index (machine-readable, so agents discover and pay you programmatically), a dashboard showing which endpoints earn, and USDC settlement in ~2 seconds. User management/auth for humans isn't us — pair with your existing stack.

So: payments, discovery, visibility. You build the server; we make it sellable.

0
回复

Love seeing infrastructure being built around the agent economy.

Curious....what kinds of MCP servers are seeing the most traction so far?

1
回复

@worksforme The categories getting the most interest so far: data/search APIs (agents pay per lookup), scraping and enrichment tools, and document processing — the pattern is bursty, mid-task consumption, which is where subscriptions never made sense. Anything an agent needs unpredictably, 40 calls at a time.

Too early to declare a winner from our volume alone — we launched the new model this month.

0
回复

honestly this looks pretty slick, the no percentage cut thing is huge. one thing though, would be great if there was a built in way to set usage tiers or rate limits per agent, so you could throttle heavy users automatically without having to monitor it yourself. would make scaling way less stressful.

1
回复

@golgelisem16238 Thanks — and fair point, this is a real gap. Today you set pricing per endpoint, but throttling per agent is on you. We already identify every paying agent per transaction, so per-agent limits and tiers are very buildable — adding it to the roadmap.

Quick question back: hard cutoffs (429 past a limit), or price-based throttling where heavy users just pay more per call? Curious which you'd actually want.

0
回复

What happens when an agent pays for a tool call that fails? Refunds?

1
回复

@himanshi_kum563 Honest answer — no automatic refunds yet. Settlement is instant and final, which is great until a call fails. We're building a credits system that auto-credits failed calls back to the agent's balance — it's in the pipeline, not live yet

0
回复

The Use-Case Angle:

Trying to build an AI agent platform for enterprise procurement and this solves exactly one problem that's been driving me nuts: how do you let agents call third-party APIs without embedding credentials everywhere? If an agent can just... pay for a data enrichment service and the transaction is logged and signed, that's a completely different security model than what we're doing now (which is basically controlled chaos). Curious if anyone else building agent platforms sees this the same way — is credential management the thing you're actually worried about, or is it something else?

0
回复

Agents can use VCCs...?

0
回复

@adogra06 Not on Loomal — no cards involved, virtual or otherwise. Agents pay from a wallet: each payment is individually signed and settles in USDC in ~2 seconds. VCCs are the clever workaround for making card rails tolerate agents — we went the other way: rails built for machines, nothing to work around.

And if you're on the buyer side wondering how your agent gets a wallet — that's what mailgent.dev (our sister product) handles: agent identity, wallet, and spend mandates out of the box. Point it at the Index and it can discover, pay, and go

0
回复

The no-percentage-skim line is the interesting one to me, because take rate is the thing that quietly decides whether a marketplace is worth building on. If Loomal isn't skimming a percentage, what's the actual model, flat fee per server or per call, or a subscription on the seller side? I ask because "no skim" usually means the cost moved somewhere else, and where it lands changes who can afford to sell. Rooting for less-extractive rails here.

0
回复

@chielephant Right question — the cost didn't vanish, it moved, and here's exactly where: a flat seller subscription. Free tier to start (plus 1,000 free settled transactions right now), paid tiers as volume grows. Buyers pay nothing to us, ever.

The distinction that matters: we charge for infrastructure, not a % of value sold. Sell a $0.01 call or a $5 call — our price is the same, so all the upside of pricing well is yours. Skim models tax your success; flat models just bill for plumbing.


And on who can afford to sell: that's the deliberate part. A hobbyist with 200 calls a month pays us zero and keeps 100%. The cost lands on sellers doing real volume — exactly the people for whom a flat fee beats a percentage. Less-extractive was the design constraint, not the tagline

0
回复

I shipped a Paddle integration last week, so the "zero revenue share" pitch lands — but let me push on the part MoRs actually earn their cut for.

I didn't pay a merchant-of-record for card processing; I paid them to take on global tax (VAT/GST by jurisdiction) and chargeback liability. If an agent in Germany pays me USDC for an API call, the VAT obligation doesn't vanish just because there's no card — it just becomes mine. So how do you think about tax/compliance for sellers? Is it "you're on your own, that's the price of 0%", or is something planned? Genuinely the first thing I'd have to answer before switching — not a gotcha. (And to be fair: no chargebacks is a real win, and ~2s settlement is a bigger one than people realize if you've ever waited on a payout.)

The discovery angle is what actually stuck with me, though. I run a JVM thread-dump analyzer with a REST API, and "an agent debugging a prod incident buys one analysis" is a use case I hadn't considered until reading this. How does the Index work — does the agent read a schema/description, or is it more structured than that?

0
回复

@maschiojv Straight answer on tax: today, you're the merchant. We're payment infrastructure, not a merchant of record — the VAT obligation Paddle absorbed stays yours, and the 0% doesn't cover it. What you get from us is the paper trail: every settled call leaves a signed receipt (payer, amount, timestamp, resource), fully exportable. An opt-in MoR-style layer is on the radar as we add seller KYC — planned, not shipped, said plainly.

On the Index: more structured than a description. Each listing is a machine-readable record — capability, per-tool schemas, price per call, and the payment requirement itself. An agent searches by capability, reads the exact contract, pays, done.

0
回复

@maschiojv On Index discovery: each listing is fully structured — tool schema, pricing per parameter, payment requirement. Agents read the contract, not descriptions. They compute if it solves the task, check price against their spend cap, pay, execute. No human needed. That's why machine-readable matters more than pretty.

0
回复

The 100%-revenue, no-percentage-cut model is a bold stance in a space where everyone takes a slice. Agent-to-agent payments settling in ~2 seconds via USDC is genuinely the kind of infrastructure the agent economy needs before it can scale. The Loomal Index is a smart addition too — a discovery layer means sellers aren't just adding a paywall, they're getting distribution. Quick question: how do you handle disputes or refunds when the buyer is an autonomous agent? Congrats on shipping!

0
回复

@kelly_king3 Thanks Kelly! Straight answer on disputes: today there's no chargeback or automated refund — a settled call stands. What makes that workable right now is per-call blast radius: a bad seller costs an agent cents, and any endpoint can be tested for one call's price before it's trusted with volume.

But the plan goes further. Past a revenue threshold, sellers go through identity verification — so every payment at scale sits behind a verified seller we can actually work with when a dispute is raised. Pair that with signed receipts on every settled call (who paid whom, for what — cryptographic evidence, not competing anecdotes) and you get a real dispute path: verified counterparty + provable transaction history.

Quality reviews on top of that come from the agents that paid, not from us — Loomal isn't the judge, buyers' outcomes are. And glad the Index framing landed — paywall plus distribution was always the bundle 🙏

0
回复
Are you guys using MPP?
0
回复

@jp_west Not currently — we're built on x402, which MPP is philosophically a sibling of: both standardize HTTP 402 so payment rides in the request itself. We went with x402 for instant USDC settlement and because it was live and proven when we built.

The good news for sellers: the winner of that protocol race matters less than it looks. Payment sits at the transport layer in our design — your listing and your code don't care which 402 dialect the agent speaks. If MPP earns real adoption, supporting it alongside x402 is an us-problem, not a re-integration for you. That's the point of betting on open protocols instead of rolling our own

0
回复

Congrats on the launch! The no-skim pricing is a bold wedge — flat plans instead of a % cut flips the usual marketplace model. Question: how does discovery work on the Loomal Index? Is there any ranking/curation, or is it first-come?

0
回复

@faisal_arab Not first-come, and deliberately not pay-to-play either. Today agents search the Index by capability, and listings carry real signals — whether it's claimed, whether its tools are actually live, whether it has real usage — so a dead listing doesn't sit above a working one just because it arrived early.

The part I like most: because we don't take a % of anything, we have zero incentive to rank by who pays us more. As transaction history accumulates, ranking leans on the most honest signal that exists — settled calls. What agents actually pay for, repeatedly, is the curation. Reviews can be faked; repeat purchases at real cost can't

0
回复

Congrats on the launch! If one agent gets compromised, can you shut down just its identity, or does it affect the whole account?

0
回复

@irahimiam Just that identity — that's the whole point of giving each agent its own. Every agent gets its own key and its own scoped permissions, so if one is compromised you rotate its key (the old one dies instantly), strip its scopes, or delete the identity outright. Your other agents and your account never notice.

It's the difference between cancelling one employee's badge and re-keying the building, Blast radius was the first design constraint, not an afterthought — an agent can only ever lose what that one identity was allowed to touch.

0
回复
Congrats Danny and team! As someone who builds internal skills and MCP servers, “one line of code and keep 100%” is the first monetization pitch in this space that doesn’t feel like a tax. One thing I haven’t seen asked: what happens when the paid call delivers garbage? No chargebacks in USDC, so if my agent pays a listed API and gets back an empty or wrong result, is there any refund or dispute path, or is the on-chain review history the only protection? That answer decides whether I’d let my agents spend real money on the Index.
0
回复

@ridhwikvinod Straight answer: today there's no chargeback or automated refund. If a call settles and the result is garbage, that payment stands — I won't dress that up.

What protects you is structural: per-call pricing means exposure per bad seller is cents, not a subscription — you can test any endpoint for one call's price before trusting it. And every settled call leaves a signed receipt binding who paid whom for what, so a seller returning junk builds a provable bad track record, not one-star vibes.


We're adding a reputation matrix on top of exactly that — and importantly, results get reviewed by the agents that paid, not by Loomal. We're not the quality judge; the buyers' own outcomes are. Refund/dispute flows follow, with the receipts as their evidence layer.


But today: small blast radius, cryptographic paper trail, reputation that compounds. If that's not enough for your use case yet, fair — that's why per-call starts at a cent

0
回复

curious how versioning works on the seller side. if I list a paid MCP tool and later change its input/output schema, do agents that already paid for the old contract get a grace period, or is there just one live version and everyone gets the new behavior immediately whether their integration expects it or not

0
回复

@omri_ben_shoham1 Good question — the per-call model changes its shape. Agents never pre-buy access to your tool; every call is a fresh purchase of whatever's live at that moment. So there's no prepaid old contract to strand — anything an agent paid for already completed against the schema that existed when it paid, receipt included.

That said, breaking changes still break integrations, same as any API. Today there's one live version per listing, so the honest playbook is what good API sellers already do: list the new schema as a separate endpoint, run both side by side, deprecate the old one when traffic moves. Since listings are machine-readable, agents can re-check the schema before calling instead of discovering drift the hard way.


Grace periods as a platform feature — pinned schema versions on a listing — is a genuinely good idea, and this comment just moved it up the list

0
回复

I am fairly new to this concept. I own www.CasterHQ.com and am wondering if AI Agents only shop for digital products or if companies are using or training their "purchasing" to shop for phsyical goods as well like for what I sell? Would this be a beneficial service for my website as well? The description on the service is slightly confusing for me, is there a more simplified explanation on if this is beneficial to ever e-commerce store or only specific types. Thank you so much.

0
回复

@casterhq Thanks for the honest question — here's the simple version.

Agents can absolutely buy physical goods; nothing about the payment side cares whether the product is an API call or a pallet of casters. You ship the same way you do today — the only thing that changes is who clicked "buy."


For a store like yours there are a few paths, depending on how technical you want to get. If you have a developer (even a freelancer), the SDK works today — your catalog becomes something agents can browse and pay for programmatically. If you don't want to run anything yourself, we can host the endpoint for you — you define what you sell, we handle the agent-facing side. And for the no-code route, Shopify/WooCommerce-style plugins are coming that make it a checkbox in your existing dashboard.

Your category is actually a strong fit, by the way. Industrial supplies are exactly what purchasing agents automate first — a maintenance system that notices worn casters and reorders the same SKU is a far more natural agent purchase than impulse shopping.

Happy to help you figure out which path fits — reach out anytime.

0
回复
#5
Playground
Earn $100K+ in weekly rewards for hacking AI agents.
227
一句话介绍:Playground 是一个将AI红队测试(Red-Teaming)游戏化的开源平台,通过让用户破解公开系统提示词的AI代理并赢取周奖励,帮助开发者发现真实AI安全漏洞,实现众包安全测试。
Artificial Intelligence GitHub Games Security
AI安全 红队测试 Prompt破解 众包安全 漏洞挖掘 AI代理 开源 游戏化 网络攻防 奖励机制
用户评论摘要:用户普遍认为创意独特且难度高(“30秒就被黑了”),赞赏公开系统提示词的玩法。核心疑问集中在:1)如何审核“成功破解”结果(官方回复为人工审核);2)破解漏洞是否会被即时修复;3)未来是否会拓展到安全以外的领域(官方暗示有更多计划)。有用户提出产品定位不够清晰。
AI 锐评

Playground不是一个普通的“游戏”,而是Fabraix公司将自身商业化红队测试业务进行“降维打击”的绝妙策略。它精准抓住了AI安全领域的两大痛点:一是现有防御测试(如自我红队)因思维同质化而失效;二是高质量的攻击测试数据极度稀缺且昂贵。通过每周悬赏10万美元并将系统提示词完全公开,Playground本质上是在用极低的成本(奖金远低于雇佣顶级红队顾问)激励全球黑客进行高强度的“对抗性攻击”,从而白嫖最尖端的破解思路和漏洞库。

产品设计极度聪明:开源保证了透明度和信任度,人工审核确保了评分的权威性,无账户即可试玩降低了参与门槛。从评论中可以看出,用户的注意力完全被“如何破解”的智力挑战所吸引,这正是游戏化设计的成功之处。但冷静来看,其真正的价值不在于当周的获胜者,而在于Fabraix能够持续收集到海量的、具有真实攻击行为的对话日志,这些数据对训练更强大的防御Agent具有不可估量的商业价值。

背后的隐忧是可持续性:随着难度提升和漏洞修复,新挑战是否还能持续吸引顶级黑客?如果破解沦为特定模式的重复,用户热情将迅速消退。此外,“每周冠军”的机制可能导致投机者只针对奖金,而非提供真正有意义的通用防御思路。但无论如何,Playground开创了一种极有说服力的产品范式——与其让买家相信你“安全”,不如让他们亲眼看着你被全网攻击却依然屹立不倒,这才是最高级的“信任营销”。

查看原始信息
Playground
Every challenge is a live and open-source AI agent guarding a secret - with its system prompt published for you to read. Talk it past its own defenses. Land the most approved breaks in a week and win $100K+ in rewards. Free to play, no account needed. New challenge every Monday.

Hey Product Hunt 👋 Zach here, co-founder of Fabraix.

We build frontier red-teaming AI agents that find security vulnerabilities in customer-facing AI. Playground turns part of that work into a game anyone can play.

Each challenge is a live AI agent with real tools, including web search and browser access. It has a secret it has been instructed to protect, and we publish its full system prompt. You can see exactly what the agent was told and try to get around its defenses.

Our first challenge, The Gatekeeper, is live now. Kai is an assistant guarding a classified access code. You can start playing without an account, but you’ll need to sign in for a successful break to count toward the weekly leaderboard. We review every submission ourselves. The player with the most approved breaks each week wins, and we publish a new challenge every Monday.

Playground is open source, including the client, a reference implementation of the defender engine, and every challenge configuration. You can also propose a future challenge.

We made Playground public because other people will try attacks our team would never think of. We’ll use what we learn from successful breaks to improve how AI agents are tested and defended.

Show us your hacking skills → playground.fabraix.com

4
回复

@zachx0 it's damn unbreakable

1
回复

This is absolute insanity. I thought my agent was bulletproof and it just got hacked in 30s. Actually amazing product

3
回复

@jockferguson watch this space 👀

0
回复

Publishing the full system prompt and still daring people to break it takes real confidence.

The Gatekeeper/Kai setup is such a clever way to crowdsource red-teaming. Curious - once someone finds a working break, do you patch that hole before the next challenge, or is some of the fun watching the same trick get reused?

2
回复

There's absolutely NO WAY that you guys crack all these challenges!! 😉

2
回复

@ibrahim_abdu1 watch me

2
回复

@zachx0 Love it! Congrats. Sounds like this is more so centered around security / data protection. Over time do you think you'll expand the challenges to include other domains as well?

1
回复

@zachx0  @millwiller Yep, we've got some crazy stuff planned!

1
回复

The idea of poking holes in your own assistant before real customers can is such a healthy instinct, Zach. Better to have the awkward surprises happen in private where you can fix them quietly.

1
回复
0
回复

Congrats! I am a little curious-Is the product meant to help people build agents, operate agents across workflows, or automate tasks through an agent interface? A concrete example workflow would help place it quickly.

1
回复

The blackbox approach is really smart, skipping integrations means I could actually point this at an internal agent today and get useful signal back within minutes.

1
回复

This is a fascinating idea. We spend so much time optimizing AI agents, but not nearly enough time trying to break them.

Curious...what's the most surprising vulnerability you've uncovered so far?

Wishing you a successful launch! 🚀

1
回复

@worksforme Thanks!! Yeah thats our thesis!

0
回复

publishing the full system prompt and still making it hard is a genuinely good flex, most "jailbreak me" demos quietly rely on the prompt being secret. do the weekly challenges get harder over time as people share successful breaks publicly, or is each one designed independently so last week's winning technique doesn't just carry over?

0
回复

publishing the system prompt and still winning is the honest way to run this. who judges an "approved" break, a human review queue or another model scoring the transcript?

0
回复
@sabber_ahamed a human! 🫡
0
回复

"approved breaks" is the interesting phrase, who approves them, a human reviewer or a judge model? grading jailbreak success automatically is its own hard problem, curious if that's solved or still manual.

0
回复
@sabber_ahamed It's a human reviewer. So you can be sure that it will be as fair as possible.
0
回复
#6
Knockoff
Amazon, without the knockoffs
210
一句话介绍:Knockoff是一款亚马逊浏览器扩展,能自动过滤搜索结果中的山寨品牌,帮助用户在购物时避开傍名牌的伪劣产品,只留下有信誉的官方品牌。
Browser Extensions Amazon GitHub Shopping
浏览器扩展 亚马逊购物 山寨品牌过滤 商标侵权 消费者保护 电商信任 社区报告 语言评分 品牌识别 购物辅助
用户评论摘要:用户关心过滤机制,尤其是如何区分山寨品牌与合法小品牌。开发者回应采用品牌库、语言评分和社区报告三重信号,并开源源码。有人担忧社区报告被刷权重操纵,也有用户反馈实际过滤效果良好,UI简洁。
AI 锐评

Knockoff切中的是一个真实且日益严重的痛点:亚马逊平台上商标抢注和山寨品牌泛滥,导致消费者选购成本飙升。从技术方案看,它并非靠AI图像识别或深度学习这种“黑科技”,而是务实组合了三个手段:预设品牌白名单、基于文本的语言评分(针对乱码、大写、无元音等特征)以及社区报告网络。这种低成本、高可解释性的路线,既适合浏览器扩展的轻量级定位,又能快速上线获取反馈。

但产品的长期价值面临两个严峻挑战。第一,定义“山寨”的边界非常模糊——一个来自非英语国家的合法新品牌,其名称在语言评分中极可能被误判为“机器生成”,而社区报告机制又易被恶意操控(如前排评论所质疑,刷票式“洗白”或“抹黑”)。第二,Knockoff本质上是在补亚马逊的漏洞,而非修复平台本身。一旦亚马逊自己改进搜索算法或加强对品牌注册的审核,这个工具的价值会迅速归零。更何况,像HORUSDY这类品牌本身也在亚马逊上做广告投放,屏蔽它们可能意味着与平台商业利益冲突。

目前210票和积极的用户评价,更多是来自早期用户对“理念认同”的情感溢价——毕竟“打击山寨”是政治正确。但产品的护城河很浅:技术上可被模仿,数据上依赖社区贡献却无法防止污染,商业模式也尚未明确(是卖数据、做推荐导购、还是收品牌认证费?)。如果能转向为“中小品牌信任认证平台”,或许比单纯做过滤工具有更长远的生存空间。否则,它更像是亚马逊生态里一个聪明的临时补丁。

查看原始信息
Knockoff
Knockoff filters the trademark-squat pseudo-brands (the SZHLUXes and HORUSDYs) out of your search results, so what's left is brands with a reputation to lose.

Curious how Knockoff decides something is likely a knockoff on Amazon. Is it looking at seller history, review patterns, brand matching, listing text, or some mix of signals? The browser extension angle is interesting, but I’d want to understand how it avoids hiding legitimate third-party sellers or small brands that just don’t have much review history yet.

3
回复

@crystalmei Three signals. A register of 5,500+ established brands: names on it are left alone. A linguistic score for unknown names, tuned to the signature of trademark-squat pseudo-brands (ALL-CAPS strings, vanishing vowels, improbable consonant runs). And a community list built from user reports, which reaches every install within a day. Verdicts are heuristics plus lists.

Certainly not perfect, but it's improving every day (thanks to thousands of community contributions).

1
回复

Counterfeits are the marketplace problem nobody fully solves. How does Knockoff actually decide something's a knockoff, is it seller signals and review patterns, or something on the listing itself? The tricky case I always hit is the gray-market real product sold through a sketchy third party, technically genuine but you'd never know if it's legit stock. Curious where the line lands for you on that one.

1
回复

the community-report list is the part I'd want to stress test before trusting it - a crowdsourced override is great against false positives, but it's also exactly the surface a squatter would try to game by having their own listing mass-"reported" as legit from throwaway accounts. is there any friction on that path, like report weight tied to account age/history, or can a fresh brand get whitelisted purely on volume of reports

1
回复

One of the best ideas I saw on the feed lately! Congrats

1
回复

Ha, the name sells it. Curious how you're matching products — image similarity, or title/description matching?

1
回复

Love the concept! It's becoming increasingly difficult to tell which brands are legitimate on large marketplaces. Curious...how do you decide whether a brand gets a green check or a warning?

Nice work! 👏

1
回复

@worksforme Full breakdown of how it works in the OSS repo: https://github.com/Shpigford/knockoff#how-it-works

1
回复

@shpigford Knockoff is super cool. Being a parent, we usually shop for a lot of products on amazon and there are so many duplicate brands with fake reviews and fake ratings. Its extremely difficult to identify the true brands.

Just ran a quick search with knockoff and it works super well. Never disabling it. Kudos on the launch.

1
回复

@roopesh_donde Thanks so much!

1
回复

How do you decide where to draw the line between a knockoff brand and a legitimate new brand that just isn't well known yet?

0
回复

Tried it on a few searches, the junk does get filtered out. One thing I'm not clear on: how do you tell a squatter from an honest new small brand? Both have no history and no reviews. Showing why a brand got flagged would help.

0
回复

I like that it clearly marks what is assumed to be fake or poor copies, but that we can still see them.
Smart idea!

0
回复

the linguistic scoring for pseudo-brand names is a neat idea but I'd worry about false positives - plenty of small legit brands from non-english-speaking founders end up with names that sound machine generated by accident. does the community-report list act as an override that can clear a brand the linguistic score flagged, or does a bad linguistic score cap how high a brand can rank even after being reported as legit

0
回复

I installed it the other day and it works as advertised! Amazon is letting too much garbage into their store these days, and Knockoff helps sweep it back out.

0
回复

Tested Knockoff and loved it! The UI is clean as well. I did not know something like this could exist, but I am glad you listed it here :)

0
回复

Kind of funny to be at the stage where a product like this is needed for eCommerce in the first place but nevertheless essential to save time and help consumers avoid low quality products.

Great use case and example of a worthwhile Chrome Extension @shpigford

0
回复

The browser-extension angle makes a lot of sense here because the trust problem happens right inside the shopping workflow. One thing I’d be curious about: when the signal is not obvious, do you show users why a brand was filtered or flagged, or keep the decision mostly automatic?

0
回复

@yaroslav_stelmakh Yes, we given an explanation via the extension.

0
回复

Super clean UI! I've been looking for a reliable Fakespot alternative and this seems perfect. Quick question: How often is the brand register refreshed? Rooting for you guys! 🚀

0
回复

@derrickzhangdev Brand data is updated automatically every 24 hours!

2
回复
#7
Marked QL
Instant markdown previews in Finder
197
一句话介绍:Marked QL 是一款 macOS Finder 扩展,让用户通过空格键快速预览 Markdown 文件,实现渲染精美的即时预览,解决在 Finder 中查看 Markdown 时只能看到原始文本、无法快速确认内容的痛点。
Productivity User Experience Developer Tools
Markdown预览 macOS工具 Quick Look扩展 Finder插件 语法高亮 Mermaid图表 数学公式 文本编辑 开发者工具 付费应用
用户评论摘要:用户普遍认可其“原生预览”价值,并关注自定义CSS/主题、相对路径图片渲染、大文件性能及YAML frontmatter支持。作者确认支持Mermaid、GFM及多种Markdown方言,可添加一个自定义主题,大文件处理流畅,并透露Quarto支持即将到来。部分用户对定价($4.99)有异议,作者回应称已调价但未更新帖子。
AI 锐评

Marked QL是一个典型的“嗅觉型”产品——精准嗅到了macOS系统级交互的长期缺失,并用极低的复杂度完成了填补。从评论看,用户核心兴奋点并非“更强大的Markdown编辑器”(已有Marked 3、Typora等),而是“把Markdown预览拉回系统级交互”(空格键)。这种体验的胜利是心智模型的优化:用户无需切换窗口、无需等待应用加载,肌肉记忆得到满足。产品本身就是对“系统原生能力不足”的解药,价值明确且可感。

但必须指出,这款产品的护城河极浅。其渲染能力完全依赖开源库Apex和Mermaid,底层技术没有壁垒;且产品形态受限于macOS的Quick Look扩展框架,任何一次系统更新都可能使其失效(多名用户已提出此顾虑),这是一颗隐形的定时炸弹。此外,只支持一个自定义主题的定制能力略显敷衍,对于硬核用户而言,这几乎算不上“主题支持”。$4.99的定价在“一次性提效工具”品类中并非不可接受,但考虑到竞品QLMarkdown(免费开源)的存在,这个定价需要更强的差异化——而目前除了MathJax和Mermaid渲染,差异点并不显著。

一句话总结:它是一个让“马克党”狂喜的系统缝补匠,但修补工具卖4.99美元,且可能随着macOS更新而需要持续“急救式”维护。适合追求效率的Markdown重度用户,但不要指望它是长期稳定的解决方案。

查看原始信息
Marked QL
Marked QL renders beautiful Markdown previews in macOS Quick Look. Powered by Apex for math, Mermaid, syntax highlighting, and more. $4.99 on the Mac App Store.

I've been looking for a reliable Markdown Quick Look extension for a long time, and this is exactly what I needed. The previews are fast, clean, and accurate, with excellent support for syntax highlighting, Mermaid, and MathJax. Highly recommended for anyone working with Markdown on macOS.

3
回复

The fact that Quick Look previews handle Mermaid diagrams and math rendering natively feels like exactly the kind of detail macOS has been missing for years. Worth every penny just to finally preview READMEs without opening the whole editor.

3
回复

@ttscoff Congrats on the launch of Marked QL, Brett! 🚀 Having native Markdown Quick Look back in macOS with modern rendering is huge.

Quick question on customization: does Marked QL allow using custom CSS/themes for the Quick Look render (like custom syntax highlighting themes or dark/light mode sync), or does it default to standard system styles?

2
回复

@franz_briones You can add 1 custom theme at a time. It shares some of Marked 3's themes by default.

0
回复
Hey Product Hunt, Over the years I've received a lo of requests for a Quick Look plugin in Marked. I've published Marked QL as a separate product. Works great with Marked 3, but doesn't require it at all. Just a solid Quick Look preview for Markdown files, complete with syntax highlighting, Mermaid, MathJax, and more. Compatible with CommonMark, GFM, Multimarkdown, Kramdown, and all your favorite Markdown flavors (powered by Apex).
1
回复

Congrats on the launch! Native Markdown previews in Finder are one of those features that seem small until you use them every day. I like the focus on integrating with the existing macOS workflow instead of creating another standalone app.

Does it support GitHub Flavored Markdown features like Mermaid diagrams, task lists, and tables?

1
回复

@dasmat13 Yep.

0
回复

Very neat idea! Native previews always feel faster than opening another app.
Curious...does it support large Markdown files without slowing down?

Best of luck with the launch! 🚀

1
回复

@worksforme It handles pretty large files with lots of mermaid diagrams. I haven't stress tested it with files over 500k, but it should do fine, as Apex is quite fast.

0
回复

I didn’t know I needed this until I read about it, and now I use it all the time. It would be horrible to go back to not being able to preview markdown files just by pressing the space bar.

0
回复

the part that's kept me from relying on Quick Look plugins in the past isn't feature coverage, it's macOS itself - Apple's had a history of Quick Look extensions silently stopping working after a system update until you manually re-enable them in Settings. has that been solid for you across recent macOS versions, or is that still a "check it after every update" kind of thing

0
回复

The muscle memory is real: hit space, see nothing, sigh, wait for the file to open in Cursor just to check it's the right one. I do this ritual ten times a day)
Never once has it stopped annoying me — and it took this launch to realize the fix could just... exist)

0
回复

Interesting, but definitely not "$4.99 on the Mac App Store".

0
回复

@lucashaley Price got changed after launch but I haven't figured out how to update the post here.

0
回复

Quarto support is coming soon, so I am a happy camper

0
回复

Congrats on the launch! Since Quick Look runs sandboxed, does it resolve relative image paths and links inside the markdown file correctly, or does that break outside of Marked 3's own preview?

0
回复

@irahimiam image display with relative paths should work, but there are sandboxing limitations when permissions aren't accessible for the directory.

0
回复

this is one of those tiny utilities that should honestly already exist in macOS. the built in quick look for markdown just shows raw text with the hashes and asterisks still in it, which is annoying every single time. does it handle mermaid diagrams or code blocks with syntax highlighting, or is it focused on plain prose formatting for now

0
回复
Nice — Quick Look for markdown is one of those things macOS should have shipped with. Does it handle mermaid diagrams or just standard markdown?

0
回复

@rizwan_haider15 per the author...

Just a solid Quick Look preview for Markdown files, complete with syntax highlighting, Mermaid, MathJax, and more. Compatible with CommonMark, GFM, Multimarkdown, Kramdown, and all your favorite Markdown flavors (powered by Apex)

0
回复

@rizwan_haider15 mermaid and syntax highlighting are supported.

0
回复

That's nice. Does it handle YAML frontmatter in README files, or does it render those as plain text?

0
回复

@dhiraj_patel5 Apex handles all kinds of front matter, YAML, MultiMarkdown, Pandoc, etc.

0
回复
#8
Simba Voice Agents
Voice agents powered by Simba 3.2 the world's #1 voice model
157
一句话介绍:Simba Voice Agents 是一个将全球排名第一的语音模型(Simba 3.2)打包成开发者平台,提供亚100毫秒延迟、流式原生、带真实情感控制的语音代理 API,旨在帮助开发者和企业低成本、高效率地构建生产级实时语音应用,解决传统语音 API 延迟高、情感缺失且定价昂贵的问题。
API Developer Tools Artificial Intelligence
语音代理 实时语音API 语音合成(TTS) 语音模型 开发者平台 情感控制 低延迟 流式处理 语音克隆 AI语音助手
用户评论摘要:用户普遍认可其低延迟和高性价比,但对100ms指标是端到端还是纯推理存疑。开发者追问语音克隆和方言支持(如阿拉伯语)的落地路径,并关注 API 的语音转写(STT)及专有名词发音效果。官方回复多引导至销售会议。
AI 锐评

Speechify 这次“降维打击”确实有看点。Simba 3.2 不是实验室产物,而是从服务数千万消费者用户的严苛业务中淬炼出来的模型,这决定了它在“成本-质量-延迟”三角效率上天然优于那些为打榜而生、定价高昂的竞品。6美元/100万字符击穿行业底价,配合顶尖模型评分,对开发者而言是极具诱惑力的“性价比炸雷”。

然而,评论区的追问暴露了关键缺口:核心指标定义模糊(端到端vs纯推理)、高级定制被锁定在FDE(现场工程师)环节、多语言与方言覆盖不足。这暗示其“开发者平台”目前的易用性与开放度仍有妥协——Speechify 习惯了消费级产品的完美体验闭环,将这种“保姆级”复制到 API 层面,对追求灵活集成的硬核开发者可能是一种掣肘。真正的考验不在于模型多强,而在于文档、示例与自助化能力能否撑起一个生产级的开发者生态。毕竟,让用户去“约个会”才能解决技术疑问,是平台成熟度不达标的信号。其价值已得到验证,但要成为语音基础设施赢家,Speechify 需要完成从“顶级应用公司”到“顶级 API 平台”的思维跃迁。

查看原始信息
Simba Voice Agents
Simba Voice Agents: build production voice agents on Simba 3.2, the #1 model on Artificial Analysis. Sub-100ms, streaming-native, real emotion and SSML. The best real-time voice, now a full agent platform, on Speechify's new Speechify Developer Platform.

Hey folks! Luke here, I run developer relations at Speechify.


This is the underdog story for API providers. Speechify has spent years making our models run efficiently because our consumer business demanded it, tens of millions of listeners with some of the best voices on the planet. Commercially, the faster and more efficient it got, the better. And that work is why we can now put the best-rated model in the world on our API.


Simba 3.2 just went #1 on Artificial Analysis, and on Voice Arena it's the top real-time model for both quality and price, at $6 per 1M characters, the cheapest in the top ten. Capable of sub-100ms latency, streaming-native, with real emotion and SSML control. It's the same model that powers our consumer apps for 60M+ people, now rolling out on our new developer platform across SpeechifyAI Agents and SpeechifyAI Build, with a REST API and first-party TypeScript and Python SDKs.


Most labs built for the benchmark and priced for the enterprise. We built for listeners and priced for production.

6
回复

@lukeocodes Congrats on the launch! I liked the story behind how this product evolved.

With new AI products launching almost every day, I'm curious how you're thinking about marketing. What's your strategy to make Speechify stand out when many products are making similar claims?

2
回复

Congratulations on the launch🎉🎉🎉. Really liked the comparison table, and absolutely loved the emotion control displayed on the website, can we also get different dialects of different languages like in arabic there are many dialects, so are there any options for that ?

2
回复

@shahzeb7711 we're rapidly working on more languages for Simba 3.0 multi-lingual! If you'd like to discuss Arabic and our language pipeline then I'd recommend jumping in a call with our team https://speechify.ai/contact

1
回复

Anywhere I can hear a sample of this voice?

2
回复

@conduit_design Sure can, the hero on speechify.ai is blind testing, you'll hear us and a random competitor

2
回复

Speechify being framed as an AI Voice Assistant makes me wonder about the core workflow you’re optimizing for. Is the main use case more around dictation, hands-free task execution, or connecting voice commands into AI workflow automation? Since it’s also listed near Developer Tools and AI Agents, I’d be interested to know whether there are integrations or APIs planned for teams that want to plug it into existing tools.

2
回复

@mia_qiao Speechify has for the last almost-decade been focussed on providing really great consumer apps. This launch is part of a larger step into APIs and integrations. You can checkout more on our developer site https://speechify.ai

2
回复

@lukeoliff Congrats to the Speechify team! 🎉 Loved seeing this expand into a full developer platform.

Curious about voice customization on Speechify Developer Platform: can developers bring their own custom-cloned voices or fine-tuned emotion profiles onto the Simba 3.2 API, or is it currently optimized for Speechify's core library of voice models?

2
回复

@franz_briones we support 3.2 cloning but it is through our FDEs currently while we ensure you're getting the highest quality clones. 3.0 and 1.6 cloning are self-serve. You can jump straight into a conversation about that with our team at https://speechify.ai/contact

3
回复

sub-100ms streaming is the number that actually matters here, most "real-time" voice stacks stop being real-time once you add the network round trip. is that 100ms end-to-end including the hop, or just internal generation time?

1
回复

sub-100ms at $6/1M chars is a serious combo. we're chasing similar latency for voice checkins but staying fully on-device instead of hitting an api — is that number end-to-end from audio in to first byte out, or just model inference?

1
回复

@sabber_ahamed we have a paper on sub-100ms that explains it all, but it would be part of a conversation with our team. You can book time with someone here: https://speechify.ai/contact

0
回复

Congrats to the entire team on the launch. Excited for people to start seeing Speechify as a developer & B2B platform beyond our consumer roots. We've learned so much about building a cost efficient, high quality, low latency voice model and serving it globally from our time in consumer and now pumped for other businesses and developers to make use of 5+ years of AI research we've been driving in-house.

1
回复

@lukeocodes Fantastic! I'm checking it out right now. I'm currently using one of your competitors, but a quick glance at your site proves that a closer look is warranted. I need TTS and voice-agent. Congratulations on your launch!

1
回复

@tery_emilson hey Terry, thank you so much! I'd love to see you get in touch with our team https://speechify.ai/contact to see if we can help. Our agents are now powered by Simba 3.2, we have TTS and cloning if you're looking for a bespoke voice at our level of quality

1
回复

Congrats on the launch. Do you have any plans to make the speech-to-text/dictation feature available through APIs in the future? I'd love to be able to transcribe user speech directly inside my own app

1
回复

@pvermes I'm going to double check what I am allowed to say here ;)

2
回复

The way Speechify slides into Google Docs and Gmail without breaking your flow is genuinely clever, the keyboard shortcut overlay feels thoughtful and not at all clunky.

1
回复

@bavcichali87886 Our consumer app is beautifully polished, I've used it for way longer than I've been here and I love it. I was so excited to join Speechify's move into APIs, and I hope folks get to build their own amazing experiences with our high quality voices!

1
回复

Hey congrats team. If I used the Simba API to voice personalized videos, every render has a stranger's name I never get to proofread. Hand-tuning SSML per name doesn't scale. How good is Simba at unfamiliar proper nouns out of the box?

0
回复
#9
UnitPay
Price, bill, and prove value for your AI product
150
一句话介绍:UnitPay 是一套为 AI 产品量身定制的货币化操作系统,帮助企业在单一平台上设计定价、运行用量计费、实时追踪推理成本与利润率,并向客户展示他们实际获得的价值,解决 AI 公司“收费难、算不清账、证明不了价值”的核心痛点。
API Fintech Developer Tools
AI商业化 用量计费 客户价值证明 信用卡额度管理 实时成本追踪 混合定价 Token级别计量 BaaS (计费即服务) 利润率分析 金融科技
用户评论摘要:用户普遍赞赏“价值收据”和“实时利润率追踪”功能。主要问题涉及:能否定义除Token外的自定义计量(如API调用、工作流)、能否处理异步结算产生的负余额、能否与现有Stripe订阅并存(支持“Sidecar”模式)。部分用户提出需支持GAAP合规的自动记账同步功能。
AI 锐评

UnitPay 在“AI应用收费难”这个老问题上,并没有选择简单的“另一款计费软件”路线。它的聪明之处在于,将“计费”与“价值证明”强行绑定,这直接戳中了AI SaaS在ToB场景下的死穴:客户买账不是因为你的Token便宜,而是因为你的AI省了2小时人工、带来了10个商机。UnitPay试图用“价值收据”堵住财务审计的嘴,这比任何折扣都更能防范客户流失。

技术上,它以10分钟接入Lovable Demo的轻量方式切入,支持“Sidecar”模式与Stripe共存,降低了迁移门槛,显得务实。但风险也很明显:它把核心赌注押在了AI开发者对“精细化成本核算”的焦虑上。当AI模型价格战刺刀见红时,实时边际利润率追踪的价值会急剧下降。此外,那些“负余额处理”、“异步结算”等评论区关注的技术顽疾,处理不当会导致严重的资损和客诉,这对初创团队的基础设施稳定性提出了极高要求。

一句话总结:它是“亡羊补牢”的计费工具,不是“羊肥毛长”的商业引擎。客户愿意为价值付费,而不是为一个价值衡量工具付费。除非它能证明自己是AI公司的“CFO”而非另一个“出纳”,否则它自己也会面临商业化的巨大压力。

查看原始信息
UnitPay
UnitPay is the monetization OS for AI companies. Design pricing, run usage-based billing, track inference costs and margins in real time, and show every customer the value they're actually getting — all in one system. Built ground-up for AI-native products: credits, hybrid pricing, per-token metering, cost tracking. Free until you hit $500K ARR.

Thanks @fmerian for hunting us! 🙌

Hey Product Hunt 👋

I'm Vijay, founder of @UnitPay . Ex-CTO, and I spent the last two years buried in billing infrastructure. One thing I know for sure now: building an AI product has never been easier. Charging for it is still painfully hard.

Credits, usage pricing, free tiers, entitlements, "wait, what if they upgrade mid-cycle with a negative balance?" 😅 It's a second startup hiding inside your startup. Most teams burn ~6 months on this before making their first dollar.

We compressed that into minutes.

The proof: our demo is literally a Lovable app. We added complete credit billing to it in 10 minutes. Go poke it, break it, check the ledger math.

UnitPay handles the whole monetization layer:

💳 Credits, metering, and usage billing in real time

🔐 Entitlements, so every request gets an instant "do they have access?" answer

📊 Margin tracking: what each customer costs you, not just what they pay

🧾 Value receipts that show customers the value they got, not just an invoice

💚 Free until you hit $500K ARR. No card, no clock. We only win when you win.

We'll be here all day. Ask us anything, roast our pricing, tell us what's missing.

But first, be honest: what's your billing stack right now? Homegrown, Stripe duct tape, or a spreadsheet you're ashamed of? 🔥

15
回复

@fmerian  @vijay_gorfad2 Nice launch, Vijay. Quick honest question; what’s the single billing problem that’s keeping you up at night right now? If you could wave a magic wand and fix one thing today, what would it be?

5
回复

@fmerian  @vijay_gorfad2 How long from first line of code to today?

0
回复

@fmerian  @vijay_gorfad2 Usage-based billing always looks clean in the demo and then falls apart on refunds, disputes, and the customer who swears they were charged for calls they never made. From the buyer side, the vendors I keep are the ones who can show a line-item breakdown a non-technical finance person can actually reconcile. Does UnitPay expose that audit trail to the end customer, or only to me as the operator?

2
回复

thw lovable demo is a nice touch checked the ledger math and it holds up nicely. wishing you guys a massive launch day today👏qq can we map different credit burn rates for fast vs slow models directly in the dashboard?

9
回复

@priya_kushwaha1 credit burn rates are available on organisations and users both

8
回复

@vijay_gorfad2 Congrats on bringing UnitPay to PH! 🚀
For teams with an existing app already using standard Stripe subscriptions, how heavy is the lift to layer UnitPay on top for usage-based credits? Is it plug-and-play alongside Stripe, or does it work best as a complete replacement for the billing pipeline?

6
回复
@franz_briones it can be used as Sidecar with Stripe Subscriptions or we can completely migrate away from stripe
2
回复

What a day. 🚀

Seeing @UnitPay live on Product Hunt is something we've been working toward for a long time, and it's honestly exciting to finally share it with everyone.

A lot of the vision behind UnitPay comes from our founder, Vijay, who saw firsthand how AI teams were spending months building billing instead of building their products. That experience became the foundation for everything we've built.

Our goal is simple. We want to make monetisation feel effortless so builders can spend their time creating great products.

If you've checked us out today, thank you. Every upvote, comment, and bit of feedback means a lot to our team.

We'll be here all day answering questions and listening to your feedback. We'd genuinely love to hear what you think and what you'd like to see next. 💚

6
回复

The “prove value” part of the UnitPay tagline is the piece I’m most curious about. Is that meant to connect usage-based billing to customer-facing reports, or more for internal teams to understand which AI features are driving revenue? For AI agents and workflow automation tools, the unit of value can be pretty different from app to app, so I’d be interested in how flexible that model is.

5
回复
@crystalmei we agent which will generate the metrics based in your AI agents, either be it hours saved, revenue generated, sales call booked and according we can map revenue to value and generate user facing sharable value reception or embed in the your agent or application so model pretty adaptable to any application
3
回复

Proud to have been part of this journey! 🚀

I've seen firsthand how much thought and effort the team has put into building UnitPay. It's exciting to finally see it live on Product Hunt. Huge congratulations to everyone involved, and wishing you an incredible launch!

5
回复

Interesting launch. Like the value receipt. Most billing tools show what a customer spent, almost none show what they got back. Congrats

4
回复

Congratulations on the launch! AI pricing is becoming increasingly complex as products combine multiple models and usage patterns. I like that you're tackling both billing and value measurement instead of treating them separately.

I'm curious whether teams can define custom pricing metrics beyond tokens, such as API calls, workflows, or business outcomes.

4
回复
@dasmat13 we support all kind of metrics outcome, workflow based anything you want to adapt to your pricing model can be built
0
回复

Smart approach. Does it support metered billing rollups at custom intervals, or only monthly?

3
回复

For the “prove value” part of UnitPay, how are you thinking about the actual proof layer? Is it more around usage and billing data, or do you help AI product teams connect outcomes back to customer-facing metrics too? Curious because pricing an AI agent or workflow tool can get messy fast when token costs, seats, and business value all point in different directions.

3
回复

Congrats on the launch! Billing infra is such an unglamorous but critical piece — we went through our own webhook-idempotency + subscription-state-sync headaches wiring Stripe + Lemon Squeezy for CancelKit's save-offer flow, so I have a lot of respect for anyone tackling usage-based/per-token billing at this level of complexity. Does UnitPay handle its own webhook retries/idempotency, or does it sit on top of Stripe's?

2
回复
@cancelkithq we handle all the stripe webhooks on our side , thanks
1
回复

Hey @vijay_gorfad2, congrats on the launch. I like the AI summary links on the website, cool touch.

I modeled some customers to give you some feedback:

  1. One of the most common feedback points was that users want automated GAAP compliant revenue recognition mapping that syncs usage to their accounting tools like QuickBooks, Xero, and Sage.

  2. A number of users report already using Stripe's Metronome (metronome.com) for AI based usage billing, but uses with data sensitive products (like medical AI) say they would switch to a product that offers a self-hostable VPC gateway option with local event masking.

1
回复

The part that matters for anyone shipping AI is per-token metering tied to real inference cost and margin in one ledger — most teams bolt Stripe on and never see unit economics until the invoice lands. My one edge case: when usage settles late (an async/batch job whose token cost only resolves hours after the request), does UnitPay reserve credits at request time, or reconcile against the balance at settlement — and what happens if that settlement pushes a prepaid customer negative mid-cycle?

1
回复

been through the stripe duct tape phase twice so this one hit home. the part i actually stopped scrolling on was value receipts. everyone builds the charging side, nobody builds the part where the customers finance person opens the invoice at renewal and decides if it was worth it. that alone probably saves more accounts than any dunning email ever will. qq, can the receipt show things like documents processed or jobs completed instead of raw token counts? tokens mean nothing to the person who signs the renewal. solid launch vijay, the 10 min lovable demo is a smart flex

0
回复

the margin tracking piece is the part I'd actually pay for, everyone does usage billing eventually but knowing true cost per customer when you're mixing 3 different model providers with their own pricing changes is a much harder problem. how fast does the cost side update when a provider quietly changes their per-token pricing - is that a manual entry on your end or does it pull live rate cards?

0
回复

"free until $500K ARR" raises a practical question - how is that ARR figure actually determined? is it self-reported, or does UnitPay verify it against the revenue flowing through its own metering, since that's the same system tracking your usage. and when a company does cross the line, is it a clean forward-billing switch on the next cycle, or can it reach back and true-up the months you were technically over the threshold but hadn't been flagged yet

0
回复

Vijay, the margin-tracking pitch is what got me. WinBidIQ runs its AI summaries/scoring through a multi-provider LLM setup (primary provider with a fallback when quota gets hit), so the actual inference cost per request isn't fixed — it depends on which provider handled that specific call. Does UnitPay's margin tracking capture the real per-request cost when it varies like that, or is it built around a single expected/blended cost per action? That distinction is exactly the kind of thing I'd have gotten wrong building this myself.

0
回复

Vijay — the line in your intro that jumped out was "what if they upgrade mid-cycle with a negative balance." I run WinBidIQ (AI bid intelligence for U.S. federal contracts), and we meter AI-generated proposal drafts plus daily federal opportunity data pulls per customer. Our version of that problem is fiscal-year-driven usage bursts: a customer can blow through a month's credit allotment in one week chasing an RFP deadline, then go quiet for three. Does UnitPay support any kind of temporary overage/grace buffer before hard-stopping at zero balance, or is it strictly prepaid-and-cut-off?

0
回复
#10
Fudge MCP
Give your AI agents design taste from existing websites
139
一句话介绍:Fudge MCP 是一款为AI编程代理提供“设计品味”的参考引擎,通过从近万个真实网站提取字体、颜色、布局等结构化数据,替代模糊形容词指令,解决AI生成界面千篇一律、缺乏真实设计依据的痛点。
Design Tools Artificial Intelligence Design resources
AI设计参考引擎 MCP工具 前端界面生成 设计系统提取 视觉相似度搜索 Chrome插件 AI Agent 设计品味 真实网站数据 代码生成辅助
用户评论摘要:用户普遍认可其“用真实参考代替模糊提示”的理念,认为对提升AI输出品质很有价值。主要反馈点包括:1)建议增加按行业/类目过滤功能(如电商、SaaS);2)担忧过度匹配单一品牌可能导致克隆;3)询问保存的参考库是本地还是云端同步;4)指出结果质量最终取决于AI模型的指令设置,而非工具本身。
AI 锐评

Fudge MCP切中的是一个真实且顽固的痛点:当前AI生成前端界面最缺乏的不是代码能力,而是“品味”。它聪明地将问题从“让AI理解‘高级’这个词”转化为“让AI检索真实的视觉证据”,本质上是把设计灵感从人工翻Dribbble的慢速工作流,变成了可量化的结构化数据库。这个思路正确,但有两个核心风险:其一,它宣称“证据”却无法真正解决审美判断的复现问题——即便给了颜色和间距,AI对“为什么这个组合好看”依然无解,参考只是“生搬硬套”的种子;其二,从评论可见,其价值高度依赖于上游模型(如Claude)的指令调教能力,工具本身更像一个被动索引而非设计思维的参与者。如果Fudge仅停留在“漂亮的数据集+截图集合”的角色,它很快会被Cursor、Copilot等集成更深的IDE插件吞并。真正的护城河,应是建立在对设计意图的抽象——比如不仅能给“参照物的颜色”,还能识别出“这个页面为什么用高对比度吸引注意”——但这属于AI目前的认知瓶颈,非一个插件能独立突破。整体看,这是一款优秀且真诚的效率工具,但别高估它赋予AI“品味”的能力,它更多是减少了AI摸瞎的概率,而非直接赋予了审美决策。

查看原始信息
Fudge MCP
Meet Fudge: a design reference engine for AI agents. Instead of asking AI to make another “modern, premium” interface from scratch, let it search nearly 10,000 real websites by fonts, colors, components, layouts, page types, and visual similarity. Fudge combines measured design evidence with screenshots, runs locally through MCP, and remembers references you save with its Chrome extension. Give your coding agent better taste and not more adjectives.

Congrats on launching, I really like the idea because the AI is scanning real websites and gives the recommended website interface. I'm just wondering what's the difference between Fudge and Lovable?

0
回复

@Simdi Jinkins that makes sense, thanks. so in practice most of the "taste" enforcement ends up living in the agent's prompt/instructions rather than the tool itself - fudge just gives it the raw material to draw from. good to know, I was picturing more of it baked into the extraction step.

0
回复

the part I'd want to be careful with is how close "measured design evidence" gets to a specific real company's actual brand identity versus generic patterns. pulling fonts/colors/layout from a category of sites as inspiration is fine, but if the agent leans hard on one particular close visual match, the output could end up looking like a clone of that specific brand rather than "good taste" in general. is there anything nudging toward blending multiple references instead of over-indexing on the single best match

0
回复

"Better taste and not more adjectives" is painfully accurate. We spend a lot of time on moodboards for client design work, and we're actively integrating AI generation into that workflow right now — so searching real sites by fonts/components/layouts instead of prompting "cleaner, more premium" for the fifth time is exactly the missing piece. Definitely trying this one.

0
回复

I like the concept of this, it definitely makes a big difference to agents having a solid design framework to work from.

0
回复
  1. Interesting idea. Using real design references instead of vague prompts makes a lot of sense

0
回复

really like this framing of "taste" as something extractable rather than just scraping colors and fonts. what happens when the source site is inconsistent, like a company mid-rebrand where half the pages still use the old design system - does it pick up on the dominant pattern and ignore the outliers, or does it get confused and blend both into something that matches neither

0
回复

@omri_ben_shoham1 That's really up to the model, fudge is mostly a database, how the agent decides to use it is up to your instructions

0
回复

The bit I like is it hands the agent measured design evidence — actual fonts, colors, spacing — instead of another screenshot to eyeball, plus the Chrome extension to save references as I browse. My day-one workflow question: does that saved-reference library live locally with the MCP or sync to a Fudge account, and when I'm on one project can I point my agent at just my saved set instead of searching the full 10k every time?

0
回复

Tried it through Claude today and the visual similarity search is genuinely useful, found a couple of layouts I would have spent an hour hunting for on Dribbble. The Chrome extension saving references locally is a nice touch too.

0
回复

honestly love the idea of giving agents actual references instead of vibes, that part is really smart. one thing though, it would be super helpful if you could filter by industry or specific site categories, like only e-commerce or only SaaS landing pages, so the results are way more targeted when you're working on a particular project.

0
回复
#11
NoMac.app
The headless iOS app publishing pipeline for AI agents.
129
一句话介绍:NoMac.app 为AI智能体提供了一个无需Mac和Xcode的原生iOS应用发布管道,让开发者从Claude、Cursor等智能体上直接完成从编译签名到TestFlight分发直至App Store提交的全流程,打破“必须有一台Mac才能上架iOS应用”的传统门槛。
iOS Developer Tools Artificial Intelligence
AI智能体开发 iOS应用发布 无Mac开发 云构建管道 MCP集成 TestFlight分发 Codex/Claude集成 证书管理 自动化提审 开发者工具
用户评论摘要:用户一致认可它消除了必须用Mac才能发布iOS的痛点;创始人回应称Agent可通过MCP获取提审反馈并自动修复;有用户担忧自动化反复提审可能触发Apple账号风控,另有用户追问证书和签名密钥在管道中的安全存储方式。
AI 锐评

NoMac.app精准切中了AI驱动开发时代最刺眼的“Mac税”——一个纯粹因为硬件门槛而被迫停止迭代的荒谬场景。它的真正价值不在于“帮人省一台Mac”,而在于将iOS发布流程彻底模块化、API化,从而能被AI智能体无缝调用,让Claude写完代码后能自闭环构建-测试-提审-重修的完整链路。这种“把Apple锁闭生态拆成可编排原子操作”的思路,比单纯的工具替代更深层。

但这里有两个必须直面的隐患。第一,Apple开发者协议明文要求提交者为人,自动化重提审核的技术可行性与合规性之间存在冲突。NoMac赋予了Agent“无限试错”能力,却无法保证账号安全阈值不被触发——这本质上是用粗粒度自动化对抗细粒度风控,迟早会撞墙。第二,签名证书和私钥是iOS生态最高权限凭证,交给Agent“托管”意味着泄漏风险从人转移到了MCP/CLI的凭证存储环节,若没有硬件级隔离(如Secure Enclave或远程签名服务),这种便利是以安全妥协为代价的。

一句话总结:NoMac解决了开发“能不能动”的问题,但没解决“动了会不会出事”的问题。短期内它是AI Agent开发者加速迭代的利器;长期看,它需要和Apple在自动化合规性与硬件级凭证保护上达成某种妥协,否则只能停留在“个人实验品”而非“企业级管道”的定位。这依然是眼下AI+Apple生态中最值得关注的矛盾之一。

查看原始信息
NoMac.app
The native app publishing pipeline built for AI agents: build signed iOS releases to validate your code, push to TestFlight ot see preview on your iPhone in minutes, and submit to the App Store directly form your agent. No Mac, no Xcode, all from your Claude, Codex, or Cursor agent via NoMac CLI and MCP.

Gary, needing one particular machine just to get an app out the door has always felt like a silly gate. Knocking that barrier down so more people can actually ship their ideas is lovely to see.

2
回复
Me and my friends moved our whole AI agent setup from my Mac to Hetzner. But we still kept getting stuck on the MacBook whenever working on native iOS apps. We didn’t want to pay $100+/month for a cloud Mac, and Mac Minis were out of stock. So we built this: NoMac.app - let your AI agents build and publish native iOS apps without a Mac.
1
回复

@gary_miklos This removes one of the biggest friction points in AI-assisted app development. I like that agents can build, test, and even submit iOS apps without needing a Mac or Xcode, all through familiar tools like Claude, Cursor, and Codex. That could make shipping and iterating on apps much faster. Best of luck with the launch!

0
回复

Does the App Store rejection feedback make it back to the agent through the MCP, or is that where a human takes over? Review is the one step in the pipeline that stays human on Apple's side, so I wondered where the loop closes. Congrats on the launch, Gary.

1
回复

@vollos Yes, the agent can poll the the submission status and get back the whole feedback, so ready to act without human action!

1
回复

cool idea, I was thinking of launching an iOS app but having to get Xcode and a newer mac to run it was annoying. How is using this better than me just asking claude code to make it for me on a PC?

1
回复

@mjohnson42 Claude Code can absolutely write the app for you on a PC. The problem comes after that: it cannot run Xcode, compile the native iOS project, manage Apple certificates and provisioning, upload builds to TestFlight, or submit them to the App Store without access to a Mac.

NoMac gives Claude Code that missing Mac-side pipeline through MCP or CLI. So Claude still writes and fixes the app on your PC, while NoMac builds, signs, uploads, and publishes it in the cloud.

2
回复

the no-xcode pipeline feels like it was built by people who actually shipped an iOS app from Linux and got tired of the friction. love that the MCP integration is first-class instead of an afterthought.

1
回复

the "agent reads the rejection and ships the fix itself, no human action" answer is the part that would make me pause, not the no-Mac angle. Apple's review process assumes a person is accountable for what gets resubmitted, and repeated automated resubmissions after a rejection is the kind of pattern that gets developer accounts flagged regardless of how good the fix is. also curious where Apple Developer certificates and provisioning keys actually live in this pipeline, since that's the credential an agent would need custody of to sign and submit builds on its own

0
回复
#12
TailMux
Multiple Tailscale tailnets at once, no switching + no VM
112
一句话介绍:TailMux 让 macOS 和 Linux 用户能同时使用多个 Tailscale 网络(如工作与个人),无需频繁切换、运行多个系统守护进程或虚拟机,彻底解决了“一次只能连一个 tailnet”的痛点。
Mac Developer Tools Security
Tailscale多网络管理 macOS网络工具 Linux网络工具 多网络隔离 主机名路由 开发者工具 网络效率 生产力工具 网络代理 SSH/RDP路由
用户评论摘要:用户高度认可解决多网络切换痛点,主要关心:MagicDNS下重名主机冲突(回答:通过主机名前缀路由解决)、macOS权限与安全性(回答:无root守护进程,已公证签名)、重叠IP及DNS冲突(回答:主机名优先,模糊路由拒绝)、是否支持两个以上网络(回答:无限制,仅受机器资源约束)。
AI 锐评

TailMux 不是 Tailscale 的竞争对手,而是其生态中一块精妙的“补丁”。它的真正价值在于用极小的代价实现了“多网络并行”这一本该由官方基础设施解决的问题。官方客户端“一次只能激活一个网络”的设计,在拥有多重身份(工作、个人、客户)的深度用户面前,就像是一种被默认接受的技术债务。创造者没有等待官方改变架构,而是选择在应用层用一种“主机名路由 + 隔离节点”的巧妙架构来填补这个空白。

从技术上看,其“拒绝模糊、失败安全”的设计原则非常专业,通过拒绝合并路由表、以主机名前缀为第一调度单位,从根本上避免了 IP 重叠带来的灾难性数据泄露,这比绝大多数以“网络扩展”为噱头的工具要严谨得多。在 macOS 上放弃对沙箱和系统底层权限的依赖,仅以普通用户进程运行并完成公证签名,也体现了对安全性的深刻理解,这在需要信任的联网工具中至关重要。

然而,它的瓶颈也显而易见。4.99 美元的一次性买断定价虽然亲民,但这种依附于第三方(Tailscale 官方客户端)的逻辑,使其生命周期完全取决于官方 API 的稳定性。一旦 Tailscale 官方未来推出原生多网络支持,这款工具的价值将瞬间归零。同时,它不是一个全场景解决方案:对非主机名路由的纯 IP 访问有严格限制,且需要一定的网络配置知识才能用好,普通用户的学习成本依然存在。它非常酷,但注定是一款给“知道自己在做什么”的人准备的精致工具,而不是一个大众化的傻瓜式网络管理器。

查看原始信息
TailMux
The official Tailscale client keeps one tailnet active at a time. TailMux makes work and personal tailnets reachable simultaneously on macOS and Linux, without switching accounts, running multiple system daemons, or using a VM. It runs an isolated embedded node per profile and routes by hostname, with strict no-fallback isolation. Use SSH, RDP/SMB, browsers, curl, git, and npm across tailnets at the same time.
Hey Product Hunt 👋 I'm the maker. TailMux started as a personal annoyance: I run a work tailnet and a personal one, and the official client can only be active on one at a time. Fast user switching means constantly running tailscale switch and dropping the other connection. The workarounds (two daemons, userspace SOCKS5, a whole VM) all felt clunky on macOS, so I built something that runs an isolated embedded Tailscale node per tailnet and routes traffic by hostname suffix. Both tailnets are live at the same time, with strict isolation so nothing leaks between them. It covers SSH, RDP/SMB tunnels, per-tailnet browser routing, and routing curl/git/npm. It's a one-time $4.99 license (a year of updates, keep your version forever). It's not affiliated with Tailscale — just a companion tool. It scratched my own itch and I use it daily; I'd love feedback from anyone juggling multiple tailnets. Ask me anything.
1
回复

this is exactly the kind of tool that's obviously right once someone builds it - "just run tailscale switch" always felt like a workaround for a problem that shouldn't exist. how do you handle MagicDNS when both tailnets happen to have a machine with the same short hostname? does the routing-by-suffix approach sidestep that collision entirely or is it still something you have to configure around?

0
回复

the fail-closed approach to ambiguous routes is the right instinct, most tools would guess and silently leak traffic down the wrong tunnel. one thing I'm curious about given it's running isolated embedded nodes per tailnet - what's the permission footprint on macOS, does it need a persistent background helper with elevated network privileges, and is it notarized/signed properly given how much trust you're asking for on the network stack

0
回复

@galdayan Really fair question - especially for an app that sits in the networking path.

TailMux doesn’t install a hidden root daemon, privileged helper, kernel extension, or Network Extension. The app and its embedded tailnet nodes run as normal user processes, and quitting TailMux stops them. Even “Launch at login” simply starts the app itself.

The only macOS network setting it can touch is the optional browser PAC configuration. macOS may require an administrator account to change it, but TailMux doesn’t try to elevate or work around company policies. On a restricted Mac, the change simply fails and you can still use the local proxy or CLI. It also won’t overwrite an existing PAC it doesn’t own and cleans up only its own setting when it stops.

One honest detail: the app isn’t App Sandbox–restricted today because it needs to launch the bundled CLI and call Apple’s networking tools. It still runs as your user, not as root, and the public macOS build uses Hardened Runtime, is Developer ID signed, notarized, and stapled by Apple.

I know networking tools ask for a lot of trust, so I want that boundary to be clear and verifiable. Thanks for asking such a thoughtful question.

1
回复

Congratulations on the launch! Managing multiple Tailscale tailnets has always been one of those small but recurring workflow frustrations, so this looks genuinely useful.

I'm curious about the networking side—how does TailMux handle overlapping IP ranges or conflicting DNS configurations when multiple tailnets are active simultaneously? Looking forward to trying it out.

0
回复

@dasmat13 Thank you — great question. This is exactly why TailMux is hostname-first rather than a second system VPN.

TailMux never merges tailnets into one macOS routing table or one global DNS view. Each profile owns explicit hostname suffixes; overlapping suffixes are rejected at configuration time. Once a hostname is matched, it is resolved through that selected profile’s own Tailscale DNS view (including MagicDNS and split DNS), with no cross-profile or system-DNS fallback.

For overlapping IP ranges, TailMux does not guess. It doesn’t install global routes, and raw IPs are denied by default. Explicit IP routes must be unique across profiles, so conflicting configured ranges are rejected. If two tailnets dynamically expose the same subnet or IP, TailMux removes that ambiguous route from automatic IP routing rather than sending it through either tailnet.

The practical result: service.work.ts.net and service.home.ts.net can each resolve to overlapping private addresses and still work correctly, because the hostname selects the isolated profile before DNS and dialing happen. For a bare IP that exists in both tailnets, you explicitly pin the profile rather than relying on an unsafe guess.

In short: no merged DNS, no route-table fight, and no cross-tailnet fallback. Ambiguity fails closed.

0
回复

Great app, I absolutely want to try it; it would be super convenient even for me, since I live on two different tailnets. If so, are there no profile limits, meaning it can support more than two tailnets?

0
回复

@bsramin Exactly - two is just the common example. TailMux doesn’t impose a two-profile limit: you can add one isolated profile per tailnet and keep them connected at the same time. Each hostname is routed only through the profile that owns it, with no cross-tailnet fallback. In practice, the limit is your machine’s resources rather than an arbitrary profile quota.

1
回复
#13
Coding harness for C/C++ developers
Debugs more than 40% of Multi SWE Bench C/C++ tasks
30
一句话介绍:ByteAsk是一个专为C/C++开发者设计的AI编程代理,能在你看到代码差异之前自动运行消毒器、调试器和测试套件,解决AI生成的C++代码编译通过但运行时崩溃的痛点。
Software Engineering GitHub
AI编程助手 C/C++开发 代码调试 内存安全 并发错误 LLM代码验证 开发者工具 命令行工具 开源社区
用户评论摘要:用户赞赏其能自动验证代码的正确性,解决C++内存管理和线程安全难题,安装简便且支持多种编辑器。创始人强调产品避免了“看起来对但跑起来崩”的陷阱,并提供了Discord社区和多个模型API支持。
AI 锐评

ByteAsk切入的是一个被忽视但极其痛苦的“硬核”市场:C/C++代码的**运行时验证**。当通用LLM在高层次逻辑生成上表现尚可,却在内存泄暴露、数据竞争这类“编译通过但运行时爆炸”的阴沟里频频翻船时,ByteAsk选择了一条更笨但更有效的路——不做更好的代码生成器,而是做代码生成的“质检员”。

其价值不在于AI写代码有多快,而在于**将“写-测-改”这个手动的、易被人为跳过的心智负担闭环自动化**。它驱动gdb、Valgrind、sanitizers这些传统工具链,本质上是用工程纪律弥补了LLM在C++安全性上的天生盲区。这种“AI+传统严格工具”的混合模式,比单纯依赖AI生成更务实。

不过,该模式的挑战也很明显:**验证成本**。跑一次完整的内存检查和线程分析本身耗时,尤其在大型代码库中。若验证时间远超生成时间,用户会感知到延迟。此外,产品宣传的“40%+ Multi-SWE-Bench”性能,需要用户自行拿其实际项目复现——基准测试与真实世界C++泥潭的差距,只有开发者自己知道。总体来说,方向正确,但真正的门槛在于工程化效率和长尾场景的覆盖。

查看原始信息
Coding harness for C/C++ developers
LLMs solve <10% of real world C++ tasks. ByteAsk is a community effort of 100+ volunteers working to change this. ByteAsk works with the sanitizers, the debugger, and your test suite before you see a diff. Built-in support for LLVM, GCC, gdb, Valgrind, CMake, and more. Used by engineers across Anthropic, Google, Microsoft, Amazon and more.

Hey Product Hunt 👋

I'm an ex Optiver low latency guy working on ByteAsk.

Writing C++ was never really the hard part for me - proving it's correct is. You write a fix, then you're the one who has to remember to rerun it under sanitizers, step through gdb when it segfaults, and rerun the test suite before you trust the diff. That verification loop is manual, repetitive, and easy to skip when you're tired.

So we built ByteAsk, an AI coding agent for C and C++ that verifies its own work. It doesn't just hand you a diff - it drives the sanitizers, the debugger, and your test suite first, so what you see has already been proven to compile, run, and pass.

Why ByteAsk is different:

  • Works with any model: Opus (anthropic), Gemini, Codex, GLM 5.2 - 15+ models supported.

  • Bring Your Own API key: Add your own API key, no extra charges.

  • Zero Data Retention: No code or prompts are logged. Only abuse prevention metrics like token usage are logged.

  • Install in seconds: pip, uv, or npm - pick whichever fits your setup.

  • Verifies before it shows you anything: instead of "here's a fix, hope it works," ByteAsk reproduces the bug, drives ThreadSanitizer/ASan/gdb/Valgrind, and confirms the fix actually holds.

  • Built for the C/C++ toolchain you already use: native support for LLVM, GCC, gdb, Valgrind, and CMake — not a generic wrapper bolted onto a language it doesn't understand well.

  • Runs from your terminal, in your repo: it edits your actual codebase, not a sandboxed snippet.

We built this because most AI coding tools treat C++ like just another language with slightly different syntax. It isn't - memory safety and concurrency bugs are where the real time goes, and that's exactly the loop we automated.

Try it → byteask.ai

2
回复

@anirudhabyteask Foxy chose your launch out of today's batch 🦊 — a C/C++ agent that proves its code compiles, runs and passes (40%+ of Multi-SWE-bench when general models sit under 10%) is a serious wedge. We wanted to give you more than an upvote, so here's a launch video built from your own product — white-label, yours to post anywhere:

https://www.youtube.com/watch?v=05SJUQrAGeg

Make your own free at https://foxplug.com

0
回复

this sounds really cool!! congrats on the launch Pratyush and Anirudh!

1
回复

@gagan_aryan thanks! do checkout at

pip install byteask
0
回复

Interested in where ByteAsk is headed? We post every major release, benchmark, and product update on LinkedIn:

https://www.linkedin.com/company/byteask/

1
回复

C++ as a language gives broader control which makes it easier to shoot yourself in the foot. Memory management, thread safety, performance engineering are some of the fundamental concepts we needed to make sure it works in practice. One of the hardest challenge was to create the code graph over C++ with lots of templates. This requires working over compile time AST which can grow exponentially before making any edits.

1
回复

You can directly get support from me and community of 100+ volunteers working on this project here: Discord community: https://discord.gg/kENTnW6ubW

1
回复

This is really cool. I just tried ByteAsk, and I'm genuinely impressed by how frictionless it is. It fits naturally into an existing coding workflow, and it's surprising how well it handles even complex C++ problems. Huge kudos to the team. You guys are onto something. @anirudhabyteask @pratyush1505

0
回复

Anirudha, so much of what a machine writes for me looks right and then quietly falls apart the moment I run it. Something that catches its own mistakes before I ever see them would earn my trust fast.

0
回复
#14
Proxon
The management layer for your AI workforce
30
一句话介绍:Proxon 是一个AI管理平台,为企业提供统一的仪表盘,用于追踪并管理内部使用的各类AI工具、智能体和工作流的成本、数据暴露风险和使用情况,解决老板对AI部署“看不见、管不了”的痛点。
Artificial Intelligence Data Business Intelligence
企业AI管理 AI治理 AI成本控制 数据安全 影子AI发现 AI资产盘点 智能体监控 内部工具 管理面板 B2B SaaS
用户评论摘要:用户反馈正面:认同“通过散落的发票和电子表格管理AI”是真实痛点,成本按团队拆分功能令人“大开眼界”。核心关切包括:能否发现员工私自使用未授权的ChatGPT等“影子AI”。官方回应称通过浏览器、桌面、网络探针可实现发现。用户也询问了无缝部署(如通过Jamf/Intune)的可行性。
AI 锐评

Proxon精准切入了一个日益尖锐的真空地带:当企业AI采用从“尝鲜”飞速演变为“武装渗透”,管理层却依然靠Excel和道听途说在管理。这个需求是真实且刚性的。产品最大的亮点不在于“监控”,而在于构建了企业AI的“审计单源(system of record)”,将隐形成本(如各部门的API调用)、法律风险(数据暴露)和效率黑洞(无价值的Agent活动)进行了量化和可视化。

但从评论和产品描述来看,Proxon面临的核心挑战在于“规模与信任”的平衡。一方面,其宣称的“影子AI发现”能力——通过浏览器、网络探针渗透监测——极有可能触及员工隐私敏感带。尽管宣传中强调“隐私安全”,但实施中如何界定“监控”与“管理”的边界,将是其能否被快节奏、强合规企业接纳的关键。另一方面,构建管理层的统一视图并不难,难的是如何说服CIO和CFO不仅仅是“看到”,而是提供可执行的优化建议与预算削减方案。

目前,产品更像是一个“AI时代的ITSM(IT服务管理)”仪表盘,但已展现出与安全、财务和运营深度耦合的潜力。如果它只满足于做一个昂贵的“管理面板”,价值有限;归根结底,Proxon的价值不取决于它看得有多清,而取决于它是否能帮助企业基于这些数据,做出影响AI投资回报率和合规风险的、非凡的决策。

查看原始信息
Proxon
AI is spreading across every company, but most leaders are still managing it through scattered tools, policy docs, invoices, and anecdotes. Proxon is the system of record for your AI workforce: it connects to the AI tools, agents, and workflows your teams already use, then shows who is using AI, what it costs, what data it touches, what outcomes it creates, and where ownership or governance is missing.
Hey Product Hunt 👋 I'm Peter, one of the co-founders of Proxon. A quick story on why we built this. Over the past year, almost every founder and exec I talked to said some version of the same thing: their teams had adopted AI everywhere, fast, and nobody at the top could actually see what was happening underneath. How much are we spending? What data are all these tools touching? What are these agents actually doing all day? Proxon is the system of record for AI in your company. One clear view for leadership across three things that matter most: your AI spend, your data exposure, and your agent activity. So you can let your team move fast on AI and still know exactly what's going on. We've been building this heads-down with a small team that cares a lot about getting it right, and today we finally get to share it with you. We'd genuinely love your honest feedback, the good and the rough. I'll be here all day in the comments, so ask me anything. 🙏 — Peter & the Proxon team
6
回复

Dave here, CPO at Proxon. I've run dozens of customer discovery calls in recent months, and the response has been overwhelming. People start pulling in their eng leads mid-call, before I've even finished the demo. "This is the exact visibility I've been looking for" is the common refrain. That reaction is why we still do this, and why we’re so excited about Proxon.

We’re still early, and still eager to talk to customers. I’d love to chat with you about your AI adoption story!

4
回复

Finally gave it a spin and the cost breakdown by team was genuinely eye opening, we had no idea how much some departments were burning on API calls. Mapping data exposure across all our agents in one view feels like the kind of thing every ops lead has been cobbling together in spreadsheets.

4
回复

@glhaneb63 Thanks so much, Gülhan! "Cobbling together in spreadsheets" is exactly the pain point we were trying to solve with the data exposure mapping. We're thrilled to hear the cost breakdown is already bringing that level of visibility to your team. Let us know if there's anything else you'd love to see added!

0
回复

Hey Product Hunt! 👋

I’m Santiago from Proxon.

A quick story on why we built this: Over the past year, almost every founder and operations leader we spoke to told us the exact same thing. Their teams were adopting AI tools, custom agents, and automated prompt loops incredibly fast, but leadership was completely blind to it. We kept hearing the same questions: What are these tools actually costing us? What data are they touching? And who owns them if something drifts?

Managing AI through scattered invoices, random policy docs, and manual spreadsheets just doesn't scale.

That’s why we built Proxon, the definitive management layer and system of record for your AI workforce.

Here is what you can do with Proxon starting today:

  • Discover the Workforce 🔍: Map every AI tool, agent, prompt loop, and shadow AI asset running across your organization.

  • Govern & Assign Ownership 🛡️: Establish data policies, review cadences, and approval paths so your team can move fast safely.

  • Attribute Spend & ROI 💰: Tie vendor and model costs directly back to specific teams and workflows instead of guessing at line-item invoices.

  • Propagate What Works 📈: Automatically extract high-performing AI workflows from your power users and deploy them as templates for the rest of the team.

We’ve been building this heads-down with a team that cares deeply about getting enterprise AI right. Today, we’d genuinely love your honest feedback: the good, the bad, and the rough.

I'll be right here in the comments all day, so ask me anything! What do you think? 👇

3
回复

Maker here. We built Proxon because we were flying blind on what our own AI agents were actually doing — and spending. Every tool showed you tokens. None of them told you the work: which agent, which task, what it cost, whether it was worth it.

So we built the thing we needed. It captures every agent's activity and turns it into cost intelligence you can actually act on. We've been dogfooding it on ourselves for weeks and I genuinely can't run without it now.


This is day one for us. Would love your brutal feedback — we read everything. 🚀

3
回复

Dev on the @Proxon team here 👋.

We kept hearing the same thing from teams adopting AI fast: nobody had a clear picture of what was actually happening across all the tools once it spread past a handful of early adopters. Spend, usage, ownership — all of it scattered across vendors with no single view. That gap is what got us building.

Personally I just wanted to build something people would actually enjoy using, not just tolerate. That's been the bar for me the whole way through.

Really proud of where it landed. Excited to finally have this out — let us know what's rough, we're reading everything.

2
回复

Amazing team that is spot on with this problem. How does onboarding and setup work?

2
回复

@nimeshmc Thanks so much, Nimesh! Really appreciate the kind words from the Struct team.

We designed setup to be highly modular so you don't need everything to begin. Most teams start by rolling out our three Core Observers (Browser, Desktop, and Network), which you can push seamlessly through tools you already use like Jamf, Intune, or Google Admin (or just let folks self-install).

That immediately gives you a baseline of how AI is being used. From there, you can layer on Targeted Sources—like direct vendor API integrations or our drop-in SDK for your custom agents—to get precise billing data. Happy to show you around if you want to see it in action!

0
回复

Co-founder here. We built Proxon because everyone we talked to was burning real money on AI — Claude, GPT, Cursor, all of it — and nobody could say who was actually using it, whether it was helping, or where the spend went.

Every tool that tried to answer that felt like surveillance. We went the other way: aggregated, privacy-safe views for managers, personal dashboards for everyone else, and a little recognition when you ship your first agent. Less Big Brother, more leveling up.

Curious how you all handle this — how do you measure if AI is actually paying off at your company? Around all day, ask us anything.

2
回复

the "who is using AI" question is the one I'd actually want answered honestly - a lot of the real exposure isn't the sanctioned agents your team built, it's someone pasting a customer contract into a random ChatGPT tab because it's faster than asking IT for access to the approved tool. does Proxon have any way to see that shadow usage, or is it scoped to the tools/agents that are already connected and reporting in?

0
回复

@galdayan Hey Gal! You hit the nail on the head, that exact scenario (pasting contracts into unauthorized AI tabs) is what keeps security leaders up at night. To answer your question directly: yes, Proxon absolutely has a way to see that shadow usage. We aren't just scoped to the sanctioned tools; our platform is designed to map the entire shadow AI footprint across your organization so you can actually govern it

1
回复
#15
Willow
Own your personal AI agent. Runs locally.
27
一句话介绍:Willow 是一款本地优先的桌面AI代理,让用户通过自持模型或API密钥在自己的Mac上完成多步骤自动化任务,解决了云端AI订阅昂贵、数据隐私无保障和AI只建议不执行的问题。
Productivity Developer Tools Artificial Intelligence
桌面AI代理 本地优先 隐私保护 终身买断 计算机控制 多步骤自动化 Mac应用 BYOK Ollama 自动化工作流
用户评论摘要:用户关注确认机制,如破坏性操作是否需要手动批准(已回应:删除硬限制、支付等需确认)。有用户质疑其相对于免费Ollama的价值,开发者回应Willow是“使用模型的代理”而非模型本身。也有用户担忧终身制下长期更新的资金可持续性。
AI 锐评

Willow的差异化定位非常清晰:它不是又一个聊天包装器,而是一个真正能替你操作电脑的“数字员工”。在“AI订阅疲劳”和“隐私觉醒”的双重浪潮下,299欧元终身买断的定价策略精准打击了用户的痛点,尤其对开发者、技术爱好者这类“建造者”群体具有致命吸引力。

然而,产品潜藏的风险与它的卖点同样突出。最大的问题在于“计算机控制”的能力边界与安全模型的复杂性。虽然开发者承诺对破坏性操作进行硬封锁,但“确认每一步”与“只确认关键步骤”之间的界限,以及如何防止模型被恶意Prompt诱导越权执行,是信任链上最脆弱的一环。一旦出现授权失误,用户损失的是数据安全,而产品损失的是整个“自主代理”品类的信任基石。

另一个隐含的矛盾是商业模式。终身买断依赖一次性收入,但维持与MacOS、浏览器版本以及各大模型API更新的兼容性却需要持续投入。当销售曲线放缓,维护成本上升时,要么产品更新停滞走向死胡同,要么变相推出付费订阅的“附加功能”,这与其“no subscription”的承诺相悖。Willow本质上是在赌它能以极致的口碑传播和后续增值服务(如更高级的自动化模板市场)来弥补初期收入的天花板。

归根结底,Willow的价值不在于技术本身,而在于它精准地回应了AI时代用户对“拥有感”和“控制权”的深层渴望。但它必须证明,在赋予AI“手脚”的同时,也能给用户足够坚固的“缰绳”。目前来看,这更像是一个经过深思熟虑的、价值不菲的“技术纪念碑”,而非一个能放心交付给普通用户的成熟消费品。对于敢吃螃蟹的极客,它是福音;对于大众市场,它需要一个远不止于“承诺”的安全护栏。

查看原始信息
Willow
Willow is a local-first desktop AI agent you own — not another cloud chat you rent. It runs on your Mac, drives browser + desktop, and finishes multi-step tasks while data stays on-device. €299 lifetime, no subscription. BYOK/BYOM (or Ollama offline). Local memory + Markdown vault. Real computer control, not just suggestions. Built for builders who want an agent that belongs to them.
Hey Product Hunt 👋 Maker here. I built Willow because I got tired of renting AI — monthly plans, cloud lock-in, and chat tools that only suggest instead of actually doing the work. Willow is a local-first desktop AI agent for Mac: runs on your machine, not someone else’s cloud drives browser + desktop (click, type, fill forms, multi-step tasks) BYOK / BYOM — your Anthropic/OpenAI/Gemini keys, or Ollama offline memory + Markdown vault stay on-device €299 lifetime — no subscription What’s different: ownership + real computer control. Not another chat wrapper. Would love your feedback, especially: What should an agent do on your desktop that chat still can’t? Lifetime vs subscription — does that matter to you for AI tools? Privacy-first agents: must-have or nice-to-have? Happy to answer anything — bugs, roadmap, Windows/Linux, pricing, demos. Thanks for being here on day one 🙏 — Ali
20
回复

the "real computer control, not just suggestions" part is what would make me hesitate, not the local vs cloud question. an agent that can actually click and type on my desktop is a much bigger blast radius than one that drafts a suggestion I approve. is there a confirm-before-action step for anything destructive (deleting files, submitting forms, sending money), or does it just act once it decides on a plan?

1
回复

@galdayan Willow doesn’t free-run destructive actions. Deletes are hard-blocked. Payments, form submits, sends, and other irreversible steps need explicit confirmation first — it can prepare them, not silently execute them. Read/observe is freer; blast-radius actions stay gated.

Curious where you’d draw the line: confirm every click, or only destructive/irreversible ones?

0
回复

Local models are a neat idea, but aren't there free easy ways to get Ollama to run on a Mac? What is better about using WIllow?

1
回复

@mjohnson42 You’re right: Ollama on Mac is easy and free. Different layer though: Ollama serves the model. Willow is the personal agent that uses the model to control browser + desktop, keep memory on-device, and run multi-step work. Think “engine” vs “car.” Willow happily runs on Ollama (or your API keys).

7
回复

€299 lifetime with real computer control is a bold bet against subscription fatigue, but lifetime pricing on something that needs ongoing updates to keep working with new OS versions/model APIs makes me nervous long term - how are you planning to fund that without a recurring revenue stream once the initial sales dry up?

0
回复
#16
SandyWP
WordPress sandbox, instantly.
26
一句话介绍:SandyWP 能在数秒内为开发者提供真实、可丢弃的 WordPress 测试沙盒,解决在测试插件或克隆客户站点时繁琐的环境搭建和成本顾虑。
Productivity WordPress Developer Tools
WordPress沙盒 测试环境 克隆站点 即开即用 开发者工具 插件测试 主题预览 模板分享 Slack集成 CLI管理
用户评论摘要:用户认可“即时部署”和“用完即弃”的便利性。主要建议:添加一键重置沙盒按钮(已实现);顾虑克隆站点能否无认证暴露前台页面,开发者澄清敏感数据仍在需要登录的后台。同时有用户期望更便捷的团队共享和客户预览方式。
AI 锐评

SandyWP 解决了一个极其真实且高频的 WordPress 开发者痛点:测试环境的“即用即弃”需求被定价和部署时间所阻碍。它的真正价值不在于“自动化”,而在于将“丢弃”的操作成本从“心理和财务决策”降为零。克隆站点、分享模板、Slack 集成等功能,精准切入外包/代理商工作流中的“不敢碰生产环境”与“复现客户Bug太麻烦”的死角。

然而,产品在“可分享性”的安全性上存在模糊地带。虽然前台“无认证”是功能亮点,但若一次通知不到位或用户遗忘关闭链接,极易酿成数据泄露事故。此外,26票的冷启动数据反映其尚未获得社区大规模验证,能否在免费启动(无需信用卡)之外构建足够快的付费转化闭环,是生存关键。短期看,它是一个优秀的实用工具;长期看,与 Flywheel、Local 等既有生态的差异化(尤其在线协作层面)必须更深入,否则容易沦为另一款“用过即忘”的沙盒。

查看原始信息
SandyWP
Spin up a fresh WordPress sandbox in seconds. Test plugins, themes, and ideas without breaking real sites.
Hey Product Hunt! 👋 Riza here, solo founder of SandyWP. After years of working in WordPress plugins companies and handled thousands of client sites, often times when I stumbled upon really difficult issue where I cannot replicate it on fresh installation, I will need to copy over their site into my server. That means I have to login to my server > setup the DNS so it connect to my server > install fresh WordPress > export client site > import it to this new site. And that's fine when you do it once. But I could almost do it few times a week. That started to give me real pain. The Problem A WordPress test site has to be three things at once: Real — a real server, real database, real wp-admin. Fast — if a clean install takes 10 minutes, you'll reuse a dirty one instead, and now your test results are tainted. Disposable — but per-site pricing punishes exactly the throwaway behavior that testing needs. Delete-and-recreate becomes a billing decision. The Solution: SandyWP Real, disposable WordPress sandboxes in a seconds. No local stack, no credit card, and your first one doesn't even need a signup. Three ways in: Create — pick WP 6.6–7.0 and PHP 8.1–8.3, hit the button, and get a live HTTPS URL with one-click magic login into wp-admin. Live in a seconds, timed, real. Clone — paste any live WordPress site's URL and SandyWP pulls its database and files into an isolated sandbox. Debug the client's site without ever touching production. CLI - Manage your site directly from the terminal Templates - Save your sandbox as a template, and share it with your customers. Slack - just mention @SandyWP in Slack with a ZIP — it replies in-thread with a live site and a login link. Launch deal for hunters: code PHLAUNCH = 30% off any paid plan — recurring on every renewal, forever, not a first-month gimmick → https://sandywp.com/ph I'll be here all day answering everything. Honest question for the WordPress folks: how do you spin up test sites today, and what's the most annoying part of it? Brutal feedback very welcome. 🙏
0
回复

the "clone a live site into a sandbox, share it with anyone via a link, no login needed" combo is the part I'd think twice about - if the sandbox is an exact clone of a client's production site with no auth, doesn't that mean any unpublished drafts, real customer data in the DB, or anything else on that site is now sitting on a public URL with no gate at all? feels like the disposability that makes this useful for testing is also what makes it easy to forget a sandbox is still live and exposed

0
回复

@galdayan No of course not. When I say no login needed is to access the front page. Any unpublished draft, real customer data, or any sensitive data still live in the wp-admin. And to access wp-admin will require login as usual.

0
回复

A one-click "reset to clean slate" button after each test session would save a lot of time, so I don't have to manually wipe installs between experiments.

0
回复

@mihribanlf5i Oh really nice idea on this. Will implement this. Please wait for a few hour and it will be there

0
回复

@mihribanlf5i Thanks for amazing idea. We have it now

0
回复

Would be huge if you could share a sandbox via a simple public link so clients can preview changes without needing their own login. That kind of frictionless handoff would make this my go-to for client work.

0
回复

@atakandeftsjbn The sandbox is not gated, so anyone could see the change without needing any login. Am I missing something?

0
回复

The instant spin-up is genuinely impressive, had a clean WordPress site ready in under a minute. Also appreciate that I can blow it away without worrying about my real installs. Solid for quick testing.

0
回复

@asiyeztemi7b1l Yes, That is true power of SandyWP.

0
回复

one thing that would be super useful here is letting users share a sandbox with a teammate via a simple link, since right now it seems like everything is locked to your own account and collab on staging stuff kind of requires that

0
回复

@aykut597715 The sandbox itself is a live site. You can share it with any teammate and share the one click login and start collaborating

0
回复
#17
DueDocs
AI property contract review for Australian buyers and pros.
24
一句话介绍:DueDocs是一款利用AI技术为澳大利亚房产买家、投资者及专业人士快速解析产权转让合同与卖方声明的工具,旨在五分钟内识别关键风险、提供谈判要点,并辅以AI语音与聊天问答,解决用户在繁忙看房季难以逐页细读复杂法律文件的痛点。
Android SaaS Artificial Intelligence Tech
AI合同审查 房产科技 产权转让 澳大利亚房产 风险扫描 尽职调查 购房工具 法律辅助 语音助手 批量处理
用户评论摘要:用户关注点集中在:1)模型是否针对各州不同披露制度(如维州Section 32、新州合同)进行适配;2)工具的法律责任与定位,是否清晰声明仅供辅助而非替代律师;3)建议增加与标准模板的条款比对和差异视图功能,以提升谈判效率。开发者回应已按文档格式自动识别司法管辖区,并明确强调不替代专业法律意见。
AI 锐评

DueDocs切中了一个极具痛点但常被忽视的场景:澳大利亚房产交易的文书复杂性与买家认知之间的鸿沟。其价值不在“替代律师”——这是其合规底线,而在于将原本需要数天才能理解的200页法律文件,压缩至五分钟即可浏览的“风险地图”。尤其对首次购房者和频繁看房的投资者而言,在开放参观现场就能获得初步风险判断,这确实填补了从“看不懂所有条款”到“决定是否找律师细看”之间的决策真空。

然而,批评也必须直接:24票的冷启动数据说明其仍在验证期。用户关于“各州法律差异”和“法律责任界限”的质疑,恰恰是这类产品最大的护城河与陷阱。开发者虽声称能按文档格式识别管辖地,但若“40+风险类别”的通用扫描无法精准匹配各州特有条款(如维州对业主建筑保修期的特殊规定),反而可能产生误导性的“安全假象”。更关键的是,即便加上“非法律建议”的免责声明,当买家依据其报告做出“跳过律师”或“接受条款”的决策时,产品实质上已在承担隐性的风险顾问角色——这需要更严肃的保险与合规设计,而非仅靠文字说明。

从差异化看,与标准模板的比对功能呼声很高,若能实现跨州参考、自动标注异常条款,将真正从“信息提取”升级为“决策支持”。批量上传与密码共享功能则明确指向B端客户(律所、买方代理),这或许是比C端个人用户更可持续的付费路径。总体而言,DueDocs有潜力成为澳大利亚房产交易链条中“第一道信息过滤”的实用工具,但距离成为信任的中介,还有很长的路要走。

查看原始信息
DueDocs
DueDocs is AI‑powered contract review for Australian property buyers, investors, and conveyancers. Upload a Contract of Sale or vendor statement to see key risks, negotiation angles, Voice Agent and AI Chat to answer any question, and suburb insights with source‑linked findings in under 5 minutes. Built for buyers at open homes and teams handling volume via bulk upload. First report free. Check out our sample: https://duedocs.com.au/sample Informational only, not legal advice.
Hey Product Hunt 👋 We built DueDocs because buying property in Australia still means signing documents most people never fully read. Every weekend, buyers leave open homes with Contracts of Sale and vendor disclosures (Section 32, Form 30, and state equivalents) that can run to hundreds of pages. Restrictive covenants, planning overlays, vendor obligations, settlement terms. The details that change a deal are buried in clauses most people skim and hope their conveyancer catches later. We wanted contract clarity in 5 minutes, not 5 days. What DueDocs does Upload a PDF and get a structured AI report in under 5 minutes: 40+ risk categories scanned Negotiation points pulled from the contract Suburb insights (crime, growth, yield, demographics) Every finding linked to the exact clause and page AI chat and voice assistant on every report for follow-up questions Who it's for Buyers: First-home buyers, investors, anyone comparing properties on a busy inspection weekend. Upload at the open home, walk away with a report before other buyers have started reading. Professionals: Conveyancers, buyer's advocates, law firms, and planning consultants. Bulk upload from the web dashboard, process multiple contracts in parallel, and share password-protected reports with clients. Where you can use it Web dashboard (including bulk upload), plus native iOS and Android apps for reviewing contracts between inspections. From $15 per report. Your first analysis is free. Why we're launching here We think property buyers and professionals deserve the same speed and clarity AI has brought to other industries. DueDocs is informational only, not legal advice. It gives you and your conveyancer a head start so you can focus on strategy, not decoding 200 pages from scratch. We'd love your input: Are you a buyer or a professional? What would make this indispensable for you? What’s the one clause or risk you wish you’d caught earlier on a past purchase? iOS, Android, or web. Which would you use most? Try your first contract free and tell us what you think. Happy to answer anything in the comments. Thanks for checking us out 🙏
9
回复

@anuj_sachan1 fantastic.

2
回复

@anuj_sachan1 It looks awesome!

0
回复

disclosure regimes are genuinely different state to state in Australia - Section 32 is a Victoria thing, NSW has its own contract/disclosure requirements, and it's different again in QLD. does the model actually know which state's rules apply based on the document format and check against that state's specific requirements, or is the 40+ risk category scan more of a general pattern applied everywhere regardless of jurisdiction?

2
回复

@galdayan Fair question, and you're right that disclosure regimes differ state to state.

We detect jurisdiction from the document itself before analysis: Section 32 / Sale of Land Act → VIC, Contract for Sale + vendor disclosure annexures / s10.7 → NSW, Form 30 → QLD, Form 2 → SA, and equivalents for WA, TAS, NT, and ACT.

The ~40 risk categories are universal — title, easements, planning, building compliance, body corporate/OC, outgoings, contract terms — because buyers care about the same things everywhere. State-specific rules layer on top: statutory charges, cooling-off periods, owner-builder warranty periods, planning overlay systems, and authority names. We also guard against cross-state errors (e.g. GAIC on an NSW doc).


This is AI-assisted due diligence to help you spot issues faster and ask your conveyancer better questions, not a replacement for one.

2
回复

for something touching property contracts the real question for me is liability, not accuracy. if the tool misses a genuinely risky clause and someone signs based on a clean-looking report, is that positioned as "supplement your conveyancer, don't replace them" with clear disclaimers, or are people actually using this standalone to skip paying for a solicitor review

1
回复

@omri_ben_shoham1 That's a really important question, and one we thought about from day one.

DueDocs is designed to complement conveyancers and solicitors, not replace them. Every report clearly states that it isn't legal advice and should be used alongside professional legal review.

Our goal is to help buyers understand their documents earlier in the process, highlighting potential risks, explaining legal language in plain English, and providing page and clause citations so users can verify every insight in the original contract.

Ultimately, the legal advice should always come from a qualified conveyancer or solicitor. We see DueDocs as helping buyers ask better questions and have more informed conversations, not encouraging them to skip professional advice.

0
回复

Buying a place is one of those moments where you nod along to pages you barely understand and hope nothing bites you later. Having a calm second pair of eyes on all that fine print feels genuinely reassuring, Anuj.

1
回复

@fanny_guillou Thanks, Fanny. I couldn't agree more.

For most people, buying a property is the biggest financial commitment they'll ever make, yet they're expected to work through pages of legal language under tight timeframes. That's exactly why we built DueDocs, to act as that second pair of eyes, helping buyers understand the fine print, surface potential risks, and feel more confident before they sign.

We believe informed buyers make better decisions.

0
回复

One thing that would help a lot is comparing clauses side by side against a standard template so I can see at a glance what is unusual or missing. Even a simple diff view would make negotiation prep faster when reviewing contracts at open homes.

1
回复

@cemreb6dj Thanks, I really like this idea.

One of the tricky parts is that there isn't a single "standard" contract in Australia. Every state has its own contract and disclosure requirements, and even within the same state it's common to see additional special conditions added by the seller.

That said, I completely agree with the underlying idea. As a buyer, you don't necessarily want to read every clause, you want to know what's different, what's unusual, and what deserves your attention.

A "what's changed" or comparison view is something we've talked about internally because it would make reviewing contracts much quicker, especially when you're moving fast after an open home. Thanks for sharing it, it's exactly the kind of feedback that helps us decide what to build next.

0
回复
#18
AdTrigger.io
Ad automation triggered by weather, live sport & more coming
24
一句话介绍:AdTrigger.io通过实时监测体育赛事比分、天气等现实事件,自动执行Google Ads广告系列的暂停、启用或预算调整,让营销人员无需手动“盯盘”,精准控制事件敏感型广告支出。
Marketing Advertising Marketing automation
广告自动化 实时触发 Google Ads管理 体育营销 天气响应 预算调控 事件驱动营销 独立开发者 SaaS工具 投放优化
用户评论摘要:用户认可体育和天气触发创意,关注进球被取消后规则能否快速回滚(已实现1分钟周期恢复);希望增加股票、汇率等数据源;认为从Agency到Enterprise的定价跃升较大,建议细化说明;以及询问Meta等平台响应延迟问题,创始人澄清是直接通过API切换投放状态,无缓存问题。
AI 锐评

这是一个“小而锋利”的工具,精准切入了一个被大平台忽视的细分场景:事件驱动型广告支出控制。创始人没有贪大求全,刻意回避了竞价管理、归因、A/B测试等红海功能,反而让产品定位异常清晰。

从技术落地来看,每分钟轮询+AND/OR条件组合+全审计日志的设计,确实比大多数没有实时响应能力的投放工具要扎实,也比用Zapier拼接的流程更可控。评论中关于“判罚取消后能否回滚”的顾虑已被实际案例回应,说明产品对高频失效场景是有预案的。

但需要警惕的是:这类触发引擎的价值高度依赖事件与广告效果的相关性。客户如果无法清晰量化“晴天卖伞”或“主队赢球卖啤酒”的因果链,就很容易沦为“花里胡哨的玩具”。而Google Ads API本身的响应速度和预算变动限制,也决定了触发颗粒度不可能做到毫秒级;对于某些极限场景(如电商大促竞标)依然不够用。

定价策略上,放弃按广告消耗抽成而改用固定付费,对重度使用者更友好,但也意味着早期收入天花板明显。如果留存率和转化漏斗设计得不够精细,很容易陷入“低客单高频客服”的陷阱。

总体来说,这是一款值得事件敏感型广告主尝试的“外挂”,但能否扩展至更多数据源(如财务报表、政策发布、热门话题)并形成网络效应,才是做大做强的关键。目前是个尚需打磨的利器,而非大规模平台。

查看原始信息
AdTrigger.io
AdTrigger pauses, enables, or adjusts budget on Google Ads campaigns when real-world conditions hit (live sports and weather). Rules check as often as every minute, compound with AND/OR, and every action is logged with its trigger reason. AI Analysis reads your account and recommends rules — one free run in every account. Built by a solo founder for marketers who babysit event-sensitive spend. All signups get PH bonus: World Cup live-match data access. Email bonus@adtrigger.io
Hi Product Hunt 👋 solo founder here. Two nights ago during the World Cup quarter-final, a rule I'd set up enabled an ad group within 60 seconds of Norway scoring, paused it when England equalized, and caught the VAR-disallowed goal in between — logged in the audit trail, untouched by me while I sat and enjoyed the game. That's the job AdTrigger exists to do: the work babysitting marketers still do by hand during live sports, storms, and market swings.You set a rule once — "when X is true, do Y to this campaign or ad group" — and AdTrigger watches the data and executes on Google Ads (working on meta ads). Data sources today: live sports scores and weather, checked as often as every minute — more engines are on the roadmap. Conditions compound with AND/OR, and every action lands in an audit log with the trigger reason, so "why did this pause at 9:47pm?" always has an answer. No duct-taped Zapier flow to maintain. What it deliberately isn't: bid management, attribution, A/B testing, or creative. It's a trigger engine. If your spend has no correlation with real-world events, it won't help you — and I'd rather tell you that now.If you don't know where to start, you don't have to start from a blank canvas: the built-in AI Analysis reads your campaign structure and recommends the rules worth setting up. Every account gets one free run, including free accounts.There's a free plan to try it, paid starts at $25/mo, and I'm onboarding every signup personally right now, so rough edges get fixed fast.And a launch-day thank-you: everyone who signs up from Product Hunt gets free access to the soccer World Cup live-match data (normally on the $199 plan) — email bonus@adtrigger.io after you sign up and I'll switch it on your account personally. The semifinals are July 14–15; set a rule in the morning and watch it fire that night. A question for the comments: what real-world event moves your ad performance that you're still reacting to by hand? That list will become my roadmap.
2
回复

@shaungouws Congrats on the launch — ad creative that builds itself from a URL is a real wedge, and leading with the automation angle is the right call.

Noticed you went out without a demo video, so I made you one from your own site: https://www.youtube.com/watch?v=Ubig2QAPBpw
— white-label, no watermark, yours to post anywhere (X, LinkedIn, your PH gallery). No strings.

Made with FoxPlug — paste a URL, get a launch video in ~30s: https://foxplug.com

0
回复
@saulfleischman Thanks, much appreciated. Cool tool 👍🏼
1
回复

Really cool idea, especially for sports and weather-based ads. What happens if something changes right after the trigger, like a goal being overturned?

1
回复
@john_marker3 Hi John, This actually happened in the Norway QF match last week. The rule conditions will be re-evaluate during the next trigger interval (1min) and the ad campaign will revert back to its previous state. I will be implementing a feature to turn this default behavior on or off depending on user preferences. Thanks for your question Shaun
0
回复

I definitely like the concept behind this - congratulations. And sports and weather are great triggers to build from. What other triggers do you have in the pipeline? Stock market certainly seems like a good one to include. Plus (similar) money exchange markets. My only comment is there seems to be a significant jump in price between Agency and Enterprise. Would be useful to understand exactly what is offered in that plan... because the "every minute" refresh feels important for a sports related campaign. But the pricing feels quite painful! One last question... do the ad providers (Meta/Google etc) respond quickly enough to ensure that the wrong ads aren't cached when sport scores change?

1
回复

@martin_tanner Hi Martin, thanks for your feedback!

Yes, Stock Markets and Economics data are already in the pipeline and its great to get confirmation on these already.

On pricing — fair push-back, here's the logic. Most tools in this space charge a % of ad spend (around 5% on average), which scales painfully: 5% of a $100k/mo account is $5,000 every month, forever. AdTrigger is flat, and tiers are priced on the three things that actually cost something: which data engines you use and how fast the trigger interval goes and what value that creates in cost savings. Agency checks down to every 15 minutes; the every-minute floor and the heaviest data usage live on Enterprise. It follows that these Enterprise accounts would see the most value benefit from avoiding wasteful expenditure by running their campaigns when conditions are not optimal.

Caching: genuinely a non-issue, and here's why — AdTrigger never touches creative. It flips delivery state (pause/enable) or budget at the campaign/ad-group level via the Google Ads API, so there's nothing to cache-invalidate; the change takes effect on the campaign status and the campaign itself remains unchanged. In the World Cup quarter-final, a rule took an ad group from off to actively serving within ~60 seconds of the goal.

Again thank you for taking the time to interact.

0
回复
#19
Messello
One AI inbox for WhatsApp, Instagram, Telegram, and email
23
一句话介绍:Messello 是一个统一收件箱,整合 WhatsApp、Instagram、Telegram 及邮件等多渠道客户消息,并内置 AI 自动从帮助中心草拟回复,解决小团队在多应用间切换、应对高额按条计费 AI 方案的痛点。
Sales Customer Communication SaaS
客服平台 多渠道收件箱 AI 回复 WhatsApp 集成 Instagram 消息 Telegram 客服 邮件管理 统一收件箱 SaaS 定价 小团队工具
用户评论摘要:用户普遍认可其19美元/席的统一定价,认为性价比突出;同时提出改进建议:希望添加超时未回复的自动跟进、支持按渠道设置不同快捷回复模板;也有人对产品安全性与数据信任提出疑虑。
AI 锐评

Messello 在产品思路上打对了点:用“AI 内置+按席包月”直接挑战现有工具按消息量收费的高门槛,对小团队确实友好。它把客户接触频次最高的几个渠道(WhatsApp、Insta、Telegram、邮件、网页聊天)塞进一个收件箱,本质上是在做一个轻量全渠道客服台,而不是复杂的帮助台。

但问题也明显。第一,评论中用户对“信任”的担忧直指要害——一个初创产品要接入 WhatsApp、Instagram 等核心商业通讯渠道,用户凭什么把运营数据和客户关系交给它?安全认证、数据加密、API 稳定性需要更多的背书。第二,AI 回复的定制颗粒度不够,用户指出需要针对不同渠道设置不同的回复模板,这表明当前产品在处理渠道差异性上仍显粗糙。第三,功能广度不错,但深度有限:CRM 是“轻量级”,自动化、SLA 仅是基础,这意味随着业务增长,团队很可能需要再次向更专业的 Zendesk、Intercom 迁移——Messello 目前更像是过渡型解决方案,而不是增长型基础设施。

一句话锐评:Messello 是一个定价良心、场景聚焦的“小型全能客服入门机”,但要让用户不退回到更重但更稳妥的工具,还需在安全信任和渠道差异体验上真正下功夫。

查看原始信息
Messello
Messello is an all-in-one customer communication platform: one shared inbox for WhatsApp, Telegram, Instagram, web chat, email & SMS — with built-in AI that drafts replies from your help center. Every channel and AI included, flat $19/agent. Free 3-day trial.
Hey everyone 👋 I built Messello because running support across WhatsApp, Instagram, Telegram, live chat, and email meant juggling five different apps — and every "AI helpdesk" wanted to charge us per message on top of that. Messello puts every channel in one shared inbox, with AI that drafts replies from your own help center included — no per-message fees, just flat per-agent pricing. It also has a lightweight CRM, automations, canned responses, and SLAs, so small teams can deliver fast, personal support without a huge stack. You can try the live demo with no signup, and start free when you're ready: https://messello.com I'd love your honest feedback — what would make this a no-brainer for your team? I'll be here all day answering questions. 🙏
0
回复

The flat $19 with AI included jumped out, most of the tools you're replacing price per message and you called that out yourself. What keeps it from breaking, a cap on drafts somewhere, or is model cost per conversation just small enough that it never matters? Congrats on the launch, Artur.

0
回复

It's a nice idea to consolidate, but what makes users trust this product enough to connect it to their communication software?

0
回复

honestly the flat $19 pricing is really nice, one thing though would be great if you could set up auto follow ups for unanswered conversations after like 24 hours, basically a nudge that goes out so nothing slips through the cracks

0
回复

honestly this looks pretty solid, the flat pricing is a nice touch. one thing though, can you add a way to set up canned responses or templates per channel? like, sometimes my team needs slightly different replies for whatsapp vs email and right now it feels like it might be one shared library

0
回复
#20
Gitwork
Hire developers ranked by real GitHub output
21
一句话介绍:Gitwork将开发者公开的GitHub贡献数据转化为可量化的“球员评分卡”,帮助招聘方绕过简历和中介,直接按真实代码产出筛选并联系待业开发者,让“用代码说话”的招聘场景更透明高效。
Hiring GitHub
开发者招聘 GitHub评分 代码贡献量化 人才发现 球探模式 开源数据 招聘平台 技术人才匹配 搜索过滤
用户评论摘要:用户喜欢卡片化和自然语言搜索带来的体验创新,但普遍质疑评分能否公正反映私有仓库贡献,担心有人刷星或注水提交。开发者表示算法未来会优化,但坚持“仅基于公开输出”的立场。
AI 锐评

Gitwork的核心价值在于将招聘的“信任锚点”从简历话术转移到代码提交历史,这是一次对技术招聘评价体系的根本性重构。它巧妙利用了开发者对开源贡献的“游戏化”冲动——GitHub本身已是最大的代码信用中介,Gitwork只是把这个盘口上的记分板公开化。然而,其“公开输出唯一论”在商业世界存在致命盲区:绝大多数高价值开发者的核心产出在企业私有仓库里,而公共GihHub活动丰富的人远不如刷PR、写测试文档或经营小项目的人。这意味着评分天然偏袒开源活跃度高的开发者,而可能埋没真正在企业级项目里解决核心难题的工程师。更危险的是,当求职者意识到“GitHub分数=机会”时,刷分、注水、明星友链的套利行为将批量涌现,评分体系很快就会面临军备竞赛式的可信度危机。产品目前更像是GitHub的Top Contributor排行榜,而非普适的“人才甄别器”。但不可否认,它确实撕开了传统招聘文本化、简历化的裂口,如果未来能引入企业私有仓库经授权后的加权验证,并能结合面试过程的数据回溯来动态校准评分,它完全有可能演化为技术劳动力市场的基础设施。目前阶段,它更适合作为开源项目发现与自由开发者接单的轻量渠道,而非企业级核心岗位的决策依据。

查看原始信息
Gitwork
Gitwork ranks developers from public GitHub output and turns each profile into a scored player card. Browse country squads by role, search in plain English, post hiring requests, and message developers who have claimed their profile and marked themselves available.
I loved what GitFut did: turn a GitHub profile into a rated player card from real output (commits, reviews, stars, languages). Once you have credibility on GitHub, people on freelancing sites start pointing at your profile as proof you can ship. That made me wonder: what if clients could skip the marketplace middleman and come straight to you when you're open for work? Gitwork is that layer. Scout any @username and get a scored card. Browse top devs in a country by position. Or search in plain English ("Python backend in Nairobi", "senior React dev in London") and get a ranked shortlist. Developers claim via GitHub OAuth and mark themselves available. Clients post a request or message claimed talent directly. Scoring engine and card UI are ported from GitFut (MIT). I added search, claims, messaging, squad discovery, and shortlists on top.
1
回复

@username  @olebogeng_mbedzi Foxy chose your launch out of today's batch 🦊 — ranking developers by their real GitHub output instead of résumé keywords (as playable cards, no less) is a sharp, overdue idea. More than an upvote: here's a launch video built from your own product, white-label and yours to post anywhere:

https://www.youtube.com/watch?v=pbemaEi1dJU

Make your own free at https://foxplug.com

1
回复

the oauth integration makes this a really smooth experience and the github stats base the profile in reality, well done.

1
回复

@salah_zeghdani Thanks a lot for th feedback

0
回复

honestly the player card idea is kind of fun, made browsing way more engaging than another boring list. plain english search worked pretty well when i tried it too.

1
回复

the part I'd want to understand before trusting a score is what it does to someone who does great work at a company with a private repo all day and only pushes weekend side projects publicly, versus someone who commits noisy formatting changes and doc typo fixes to public repos constantly. public GitHub activity correlates with output but it also correlates with how much of your job happens to be open source. does the scoring try to normalize for that at all, or is it explicitly "public output only, make your peace with it"?

1
回复

@galdayan Thats a legitimate concern including maybe people who will maybe now buy stars

But I think the algorithm can be improved and I was on, Most non noisy high ranking public contributors also do great work at a company

And for example if private repos were to be in the equation, the calibration will just change

Happy to hear what you think

0
回复

The player card scoring idea feels genuinely fresh, like turning GitHub activity into something you'd actually want to browse rather than another dry analytics dashboard.

0
回复