PH热榜 | 2026-04-29

@ilankad23 neat product - keep up the great work

@ilankad23 An exciting day!

@ilankad23 This is such a great step forward - really inspiring to see this come together. Looking forward to seeing the impact it creates!

@fmerian <3

@fmerian exactly what we did! what a crazy era we live in where it's so hard to coin new concepts!

@fmerian Thanks We’re really excited and hope this product will help accelerate GenAI adoption.

@sebastian_sosa1  Our product is actually not 'Vanilla' BARRED, it's a combination between BARRED and our earlier AutoPrompt work (https://github.com/Eladlev/AutoPrompt) on intent-based prompt calibration.

The key insight: most of the time when the LLM judge are biassed, the real issue isn't which one to trust, it's that the judge itself was never calibrated to the user's actual intent. Generic judge prompts encode the prompt author's interpretation of the policy, not the user's.

AutoPrompt closes that gap. It surfaces boundary cases and asks the user to label only those edge cases (a handful of annotations, not thousands). That feedback calibrates the judge prompts to the user's true intent. We then use those calibrated judges inside BARRED's debate loop, so the synthetic training data faithfully reflects what the user actually wants the guardrail to enforce.

So disagreement isn't resolved by picking a winner. It's prevented upstream by aligning the judges to user intent before the data generation runs.

@sebastian_sosa1 We're here if you have any more questions! Let us know what you think once you try it out!

@sebastian_sosa1 Great question — this is exactly where systems either become real infra or shelfware.

Our approach (from the paper) is: don’t resolve disagreement in production, resolve it in training. Here is the link to our paper for more details about our approach (https://huggingface.co/papers/2604.25203)

• We establish ground truth via multi-agent debate (judges + advocate). Only samples that reach consensus make it into training; the rest are refined or discarded

• This gives us a high-fidelity dataset, so the SLM is trained on much cleaner signals than raw LLM judgments

• In production, disagreements (SLM vs LLM/spec) are treated as high-value edge cases, fed back into the same loop (debate → refine → retrain)

So instead of asking “who do you trust?” the system continuously earns trust by learning from disagreement

That shift is what makes it actually work.

@dmitry_zakharov_ai Let me know if you have any questions!

@dmitry_zakharov_ai go ahead! let us know what you think!

@dmitry_zakharov_ai hoping you find it helpful

@busmark_w_nika 😅 it can!

@busmark_w_nika Yes and more:)

@busmark_w_nika did you get a chance to try it out yourself?

@webappski both reads are right but for different parts of the pipeline. Synthetic data has two failure modes: diversity (covering edge cases) and faithfulness (correct labels).

Convergence on faithfulness is the test-time disagreement read: judges deliberate independently across rounds, and a sample is accepted only on judge consensus. The asymmetric design (rigid Advocate vs deliberating Judges) is where the adversarial pressure comes from, not symmetric debate.

Diversity is handled separately by dimension decomposition with verbalized sampling, plus boundary-case sampling that targets the decision boundary. That's where the adversarial-against-spec read mostly lives.

So the convergence isn't one loop. Diversity is upstream coverage, faithfulness is downstream consensus, and the debate's adversarial geometry is what makes the consensus signal informative rather than collusive.

@webappski Great point, that “doesn’t repeat → doesn’t get caught” blind spot is exactly what bites in production. On the ground truth side: it’s a mix of both. We start with adversarial generation against the task spec to surface candidate failures, then use multi-agent debate to stress and validate them until there’s strong agreement — that loop is what makes it converge without needing pre-labeled failure modes.

@webappski We're here if you have any more questions! Let us know what you think once you try it out!

@avrisimon 
Avri, the sampling point is exactly right - the failures that matter live in the tail.

on cold start: typically 1–2 iterations. When someone describes a guardrail in plain language, we decompose it into behavioral dimensions and generate synthetic boundary cases specifically designed to probe the subtle violations, not just the obvious ones. There's an adversarial validation step that challenges generated cases before they go into the training set - that's what calibrates for edge cases from the start rather than after manual iteration.

One round of enrichment usually gets you there. The system tends to surface sub-categories the user hadn't articulated - they just confirm or redirect.

@avrisimon Great question on the cold start, Avri. We invest heavily in making the system work well in zero/few-shot settings - that's actually the core novelty of our approach. You can define a guardrail in plain language and get great results even without needing labeled examples upfront.

That said, as with any ML system, more examples = better calibration on subtle violations.

Our research paper covers a diverse set of tasks where zero-shot performance is already SOTA

@avrisimon We're here if you have any more questions! Let us know what you think once you try it out!

@omri_sela2 🚀​

@omri_sela2 can you believe it's finally out??

@omri_sela2, not only what is the problem, but also by how much do we outperform GPT-5 on this task?

@arthur_romanov thank you very much! looking forward to hearing how you like it

@arthur_romanovThanks, we just getting started! exciting to see how team are using it to make thier agents reliable

@arthur_romanov Let me know if you have any questions! Thanks!

@michael_vavilov Actually, part of our contribution is that we released such a benchmark!
https://huggingface.co/datasets/Plurai/BARRED

@michael_vavilov Great question!

The 43% fewer failures comes from our research benchmarks across multiple tasks (conversational policies, agent workflows, compliance), not a single narrow use case. In the paper, we evaluate across different domains and datasets, and consistently see that task-specific models trained with our method outperform LLM-as-a-judge baselines and generic guardrails

If you want the full breakdown (datasets, tasks, and comparisons), we shared it here:
https://huggingface.co/papers/2604.25203

Curious what kind of failures you’re measuring today?

@michael_vavilov We're here if you have any more questions! Let us know what you think once you try it out!

@ben_wisbih blood sweat and tears 😀

@ben_wisbih ❤️‍🔥​

@ben_wisbihthank you! so grateful to have you with us

@tammy_wolfson2 totally!!!!

Shout-out for the awesome work on this launch! 👏👏

@redzumi Totally hear you, that’s exactly the pain we built this for.

What we’re seeing in practice is that once you move from generic LLM-as-a-judge to a task-specific SLM trained on synthetic + debate-validated data, you get:

• Fewer hallucinations / policy misses (because the model actually learns your failure modes, not generic ones)

• Much lower cost + latency (small model, real-time)

• And the ability to enforce on every interaction, not just sampled evals

It’s not magic, the key is the data. The paper shows that without proper validation, label noise kills performance, but with debate-based verification you get much cleaner signals and significantly better accuracy If you’re feeling this pain in production, you’re exactly the ICP we’re building for. Curious what kind of failures are hurting you most today?

@redzumi That's really validating what we've been hearing and the pain we want to prevent! Let me know if we managed to do it for you!

@redzumi Also, improve quality and consistency

@igor_martinyuk exactly. that's one of the challenges we have been facing and a main differentiator

You are right regarding the challenge of generating such data. You can read our previous Intellagent research paper (we also have an open-source) on our unique approach to simulation using graph-based policy decomposition:
https://github.com/plurai-ai/intellagent

@igor_martinyuk Exactly! most real failures aren’t single turns, they’re stateful across interactions.

That’s why we simulate multi-turn flows and generate edge cases across the sequence, not just isolated prompts including those “looks fine at each step, breaks at the end” scenarios.

Curious go hear what kind of multi-turn failures have you seen most often?

@sha_maayan Of course! Our approach is backed by the research and benchmarks we’ve published — you can check it out here: https://huggingface.co/papers/2604.25203

Would love to hear your thoughts on both the method and the product.

@sha_maayan We're here if you have any more questions! Let us know what you think once you try it out!

@sha_maayan Lol, we had a lot of headkcks in answering the rebuttals :).
BARRED is submitted to the current ICML, and our previous works (Intelligent, AutoPrompt), were published in ICLR DPFM and ICML data workshop

@natalie_ermishina Great question, Natalie! We use an 'intent calibration' process that fine-tunes evals and guardrails to match your subjective expectations. We generate a custom training set to demonstrate the classification, then let you iterate via an agentic experience until the results are exactly where you want them

@natalie_ermishina Thanks a lot, really appreciate it!

Great question on subjective tasks — that’s actually where this approach becomes even more interesting. Instead of relying on a generic judge, we define subjectivity explicitly (via the spec / examples), and then generate diverse boundary cases around that intent. The key is that labels aren’t coming from a single model they’re validated through multi-agent debate, which helps reduce ambiguity and noise in more nuanced cases

In practice, we’ve seen that once the SLM is trained on this kind of task-specific, high-fidelity data, it handles subjective criteria (tone, style, compliance, etc.) much more consistently than LLM-as-a-judge setups.

We go deeper into this (and share benchmarks) in the paper:
https://huggingface.co/papers/2604.25203

Would love to hear what kind of subjective evals you’re thinking about, that’s exactly where things get interesting 🙂

@natalie_ermishina We're here if you have any more questions! Let us know what you think once you try it out!

@danshipit Thank you! Looping @ilan_kadar to answer your question

@danshipit No, part of the big effort that we did was to do a very efficient deployment of the SLM (in order to provide <100ms and such low cost). We are going to release exactly how we are doing the deployment so efficiently in the coming days. But the buttom line is that we are doing the deployment on our own and not using 3rd party provider

@danshipit On the LLM optimization path we're fully model agnostic. On the SLM path we train the model ourselves on your policies — so either way, no fine-tuning on your end.

@matheus_paranhos1 Coming very soon 👀​

@matheus_paranhos1 Great question! coming really soon :)

@matheus_paranhos1 We're releasing a Claude Code plugin in the coming days that lets you work directly from the IDE and integrates the evals straight into your code.

@reut_v_plurai Great to work with you

@reut_v_plurai so glad to work with you on this

@reut_v_plurai The product behind the product and what a product it is.
Amazing work, couldn’t have done it without you, so lucky to have you with us ❤️

@boyuan_deng1 Usually, in production, there is a simple 'or' logic between all the different guardrails; if one of them fails, you block the response

@boyuan_deng1 thank you :) we're also obsessed with the framing 🤩
each guardrail returns its classification and reasoning - and your "state machine" can figure out how to mitigate between the two having the full context

@boyuan_deng1 means a lot, we're obsessed with that framing too 🙌 @reut_v_plurai nailed the answer below — each guardrail returns its classification + reasoning, so your logic layer has full context to resolve conflicts. Not just verdicts, actual signal.

@robert_douglass Thanks, we benchmark ourselves on similar use cases, but always happy to get feedback and test it on more interesting and challenging cases

lfg, Robert! give it a spin - go to plurai.ai and add your review here: https://www.producthunt.com/products/plurai/reviews/new

@robert_douglass exactly what we were aiming for! what did you think?

@dimitrioskk Go ahead!!!! can't wait to hear if we managed to serve your expectations! app.plurai.ai

@dimitrioskk thank you! would love to get your feedback on the product

@dimitrioskk Let me know if you have any questions!

@nir_diamant Thanks Nir!!! We appreciate it ❤️​

@nir_diamant thank you! it means a lot!

@nir_diamant Thanks Nir, hoping this product will accelerate adoption of AI in production

@abod_rehman In this product, it's up to the developer to provide the feedback loop (simply by uploading a new CSV with the fresh data), and trigger the training.

In our enterprise offering, we provide a platform that does it automatically

@abod_rehman great question! yes, this coming soon

@abod_rehman awesome question

@eduardo_ordax great to hear!

@eduardo_ordax Thanks! Glad you enjoy the product

@eduardo_ordax amazing!

@nastassia_k 
Thanks! I'm here if you have any more questions! Let me know what you think once you try it out!

@nastassia_k thank you! waiting for your feedback!

@nastassia_k Thank you! would love get your feedback on the product and thoughts on our approach? we just getting started!

@marko_poe Amazing! Whats your use case?

@marko_poe How much has your accuracy improved compared to GPT-5?

that's awesome - make sure to leave your review here: https://www.producthunt.com/products/plurai/reviews/new

@nikvoice thank you so much! would love your feedback!

@nikvoice We appreciate it! Did you get a chance to try it out?

@nikvoice thanks! looking forward to hear your feedback

@urieli17 Let me know what you think once you try it out!

@urieli17 it's finally here :)

@urieli17 we're here!

@jodoron Thank you!

@ilan_kadar @ilankad23 will answer your questions

@jodoron Currently LLMs, working on extension for vision

@jodoron can you provide a concrete example of a multimodal guardrail you would like to use?

@piotreksedzik 130+ engineers and 10 years of healthtech experience shows in the schema. It’s clear this wasn't just built in a weekend it’s battle-tested. How do you guys handle data backfilling for new users can we pull the last 90 days of history from Health Connect or Suunto automatically?

@piotreksedzik - This is great. I have done POC with ow in my app and is much more economical as compared to the alternatives. Just waiting for the full fitbit integration available on openwearables. Thank you!

@piotreksedzik It looks like it's a great success. Well done team!

Hi @iamanantgupta We already integrate with Apple Health and Google Health and provide SDKs for SDK-based providers - you can see providers we support and full coverage matrix in the documentation: https://openwearables.io/docs/providers/supported

@iamanantgupta Is Google Fit the same thing as Google Health? If so, we already have it.

@iamanantgupta yes, it's already there, we support ale the major providers. Still adding more to the repo (our roadmap is also public).

@itsluo That's the exact problem we keep seeing. Six to twelve months of OAuth integrations before you can ship anything meaningful kills most indie health projects before they start. Railway deploy in five minutes was a deliberate choice.

@itsluo Thanks for the feedback, that's the point exactly to use open wearables as an development accelerator for health / longevity / wellness / fitness apps to build on top (with our tools as well by the way - like health scores, agentic flows etc).

@itsluo Does the `indie health app` label fits to you company? :)

@piotr_karwatka Thanks Piotr, "data bus for health/wearables" is a sharp framing, the standardization gap is exactly what kept biting us across client projects until we decided to just open-source the fix. Appreciate the support 🙏

@piotr_karwatka FInger crossed, thanks!

@piotr_karwatka Exactly, the whole point here is to unlock the siloed health data structures. Builders and companies should be able to focus on the priorities so building health intelligence on top of wearables data (and not only!) and beyond like recommendation engines, anomaly detection, health scores etc.

But you're 100% right, prioritization, normalization, and putting that data into clinical context is the key. This is what we do in OW :)

@michal_wlodarczyk1 yes we do, each algorithm of open wearables is open and can be audited. Our Health Science Lead also runs her own substack in which she will also explain the details behind algorithms.

https://thesciencebehindwearables.substack.com/

@michal_wlodarczyk1 But to clarify that - we don't have an access to the Oura's alghoritms, nobody does. But our algorithms are accessible in our Github repo. They even have separate directory, so it's easy to find and analyse them.

@michal_wlodarczyk1 That’s a good instinct — “readiness” scores feel objective until you realize they’re really just weighted models over a handful of signals.

@zuzanna_gutkowska Thanks for following along! 😊 If you like this you may also like The Science Behind Wearabes where we dive much deeper into that: https://thesciencebehindwearables.substack.com/

@zuzanna_gutkowska Do you have your favourite Open Wearables linkdin posts series? Just curious which ones reached you ;)

@zuzanna_gutkowska thank you Zuza for your ongoing support! Super important for us!

Thanks @mikhail_prasolov ! That's actually quite tricky as the data coming from different providers is surprisingly quite different even though these are often the same pieces of information. As you mentioned these are often in different formats, sometimes aggregated or processed in some way. We've come up with what we called Unified Health Data Model and you can also see Data Types and Coverage Matrix to check what data types we support and how they are normalized across providers.

@piotr_ratkowski  @bartmichalak  @piotr_sobusiak  @mikhail_prasolov 
haha Piotr representation is strong on this team, can confirm

normalization is the boring core of the whole thing - every provider has different field names, different units, different nulls, different timestamps. we map everything to a unified schema at ingestion so whatever's above it (scoring, AI, your app) never has to care where the data came from

it's unglamorous work but it's what makes everything else possible

@piotr_ratkowski  @bartmichalak  @piotr_sobusiak  @mikhail_prasolov Our unified data model assumes that we create a Strategy class for each provider. By inheriting from an abstract base strategy, this class enforces a consistent structure. This means we have predefined areas (e.g. workouts, continuous data (sleep, HR, etc.), provider authorisation, or the method of data retrieval) and in each there are either certain gaps to be filled (e.g. workouts and continuous data require the definition of a function to normalise the data to our model, which requires knowledge of the payload coming from the provider’s API – the rest of the functions that process this normalised data are already inherited from the base strategy) or several defined paths to choose from (e.g. authorisation requires specifying the authorisation method imposed by the provider’s API, and the data retrieval method determines whether we need to query the API periodically ourselves, or whether it is sufficient to connect once and receive data almost in real time). Finally, the normalised data is sent to the database, and from there it is retrieved, for example, by our webhooks, which will send notifications to clients’ backends whenever any data becomes available.

@hex_miller_bakewell Thanks Hex - exactly the right question. Schema drift here is unavoidable, but we're trying to make it bounded. Our approach: stable versioned core for the common path treated as a contract; provider-specific quirks accessible but separate; additive changes by default; explicit deprecation windows for actual breaking changes. WorkoutDetails specifically is one of the messier surfaces - we know, we're treating it as evolving. Schema is in the repo - happy to go deeper via DM or GitHub issues, can loop in our engineering lead for a proper versioning rabbit-hole. Thanks for the kind words on the launch 🙏

@hex_miller_bakewell Thanks for the insight, super important one as well. The data schema is in the documentation. We are currently working on expanding that and will share the roadmap on GH and Discord, but if you'd like to be informed, let us know, we'll add you to the mailing list on updates.

@hex_miller_bakewell I don't think it's possible to avoid that issue anyway.

@iwan1212 "Stops the screenshot chase" might be the best one-line description of the problem we've heard. Coaches managing 20 athletes across 5 different apps is a real workflow nightmare and it's invisible until you sit with them.

Thanks for shipping with it Patryk. If you ever want to write up the deployment as a case study (or just a thread), happy to help, that story would land with a lot of teams.

@iwan1212 That’s actually the most compelling version of this story — not the aggregation itself, but removing the “screenshot + interpretation by hand” workflow from coaching entirely.

@iwan1212 Forgive me for being curios, but what type of the club is it?

@krzysztof_szyszkiewicz thank you!

honest answer: today it requires some technical setup - you need to run the platform and connect the MCP server to your AI client. not rocket science but not one-click either

the vision is exactly what you described though - ask Claude or ChatGPT "why did I sleep badly this week" and get an actual reasoned answer based on your real data, not generic advice

that's where we're going. docs here if you want to try: https://docs.openwearables.io

@krzysztof_szyszkiewicz MCPs are not that complex, but processing such big amounts of data given limited context of LLMs usually is. We already have very first version of Open Wearables MCP server (it's in the repo so everyone can use it) but it needs some polishing to call it production grade and work flawlessly with big data sets.

@krzysztof_szyszkiewicz It shold be easy to setup, but I don't think it's really that useful. Simple chat with AI agent will do a better job. And that's also going to be avilable.

@k_waraksa The 20% feeling is more common than people admit. Most apps show you the raw numbers and leave the interpretation to you. Thanks for the kind words and for vouching, Chris. We'll try not to embarrass you.😄

@k_waraksa Bevel user here too, by the way. Great product, but still a long way to go on turning that data into something genuinely actionable. Appreciate the support, lfg 🚀

@k_waraksa Chris - that 20% number is real. I run 3 platforms across my own training and still feel like half the signal is locked behind some "open the other app" wall. Vouching means a lot today. Cheers 🙏

@ragsyme A meditation app adapting to HRV and stress scores is a solid use case for exactly this. If you build it again, the stress index and HRV baseline algorithms are already in there.

@ragsyme Thank you for sharing, which data sources did you integrate in that product?

@ragsyme But it still can help you in your next projects ;)

@abod_rehman Thanks for the kind words!

@abod_rehman Some providers (Apple, yeah, it's about you!) forced us to keep an eye on that issue early ;)

@abod_rehman and good to see this open sourced as well!

@raztronaut Razi this means a lot coming from someone who's actually been in the trenches with this data. The Stripe-for-fintech analogy is exactly the framing we kept coming back to - wearables need that layer or every team just keeps reinventing the same auth + schema mess. Would love to swap notes - DM open. 🙌

@raztronaut Haha, so maybe this is time to try with another product, but this time built around Open Wearables? :D

@raztronaut wow, that's amazing! Which other health data sources did you use in that product?

@paulina_kowalczyk Two years of manual Apple Health exports is exactly the pain that shouldn't exist in 2026. Open Wearables is the infrastructure layer for that consumer product, if anyone (you?) feels like building it, we'd happily help.

@paulina_kowalczyk It's because most of the providers don't want the products like this to be available for consumer. Sadly, but this is the truth. Just look at the Garmin for example - there is no way to get API access if you are not a company.

@gregrog Thank you so much :)

@gregrog Thank you Greg! 💪

@konrad_talaga1 You're right that most platforms guard scoring as the crown jewel. We went the opposite way on purpose: black-box scores are fine until a clinician or regulator asks why the number says what it says.

Who decides: our own R&D, led by Anna Zych (Health Science Lead), grounded in published research where it exists (sleep stages, HRV, training load all have public literature) and open discussion in PRs and GitHub issues where it doesn't. Momentum's engineering team owns direction, contributors shape it. Thresholds are tunable, so if you disagree with our defaults you fork and calibrate for your population.

@konrad_talaga1 As a Piotr said. If you want to ask questions about scoring models, you can find Anna on Linkedin or our Discord :)

@konrad_talaga1 The idea behind it is that you can use our open source health scores as the foundation and then tune, refine and adjust to your population / use case. By the way, our dashboard shows a comparison between different scores (oura, whoop, garmin and more).

@worklab It's self-hosted, so you pay for infrastructure usage. As Momentum we also support custom deployment and build services around Open Wearables whenever you need building your product with our tool.

@worklab The model is that you can self-deploy and maintain it yourself or we handle that for you ( SLA, compliance, custom features). The core is about 80% done out of the box, and we customize the rest for each use case. Dozens of companies already use it for free. Larger ones work with us to tailor it to their infrastructure and maintain it long-term as self-hosted, full control over their data pipelines, with intelligence built on top: like health scores, recommendation engines, anomaly detection, and more.

@worklab You don't pay, thats the trick ;) Its license is MIT.

@agata_wieczorek Thanks Agata! OW is a developer infrastructure, not a consumer product. There's a developer portal for managing the deployment (users, OAuth credentials, debugging), but end users see whatever dashboard you build on top. Some teams ship their own UI, others embed widgets we provide.

@agata_wieczorek As Piotr said, there is only a dashboard for administrators. So company using Open Wearables as a platforms has to create it's own UI for regular users.

@agata_wieczorek it is mostly b2b / devs but you can also run your own instance with one click deployment on Railway and play around with your data through MCP server we provide 🙂

@anton_zaporozhets1 Fair question. Both have official OAuth-based developer programs, and we've been shipping against them long enough to know the quirks (Garmin especially took real engineering time). If a provider changes something breaking: we patch, you pull the update. That's the OSS advantage. With a SaaS aggregator you wait for the vendor's roadmap and keep paying while you wait. No third-party integration is fully immune. The difference is how fast the fix lands and whether you can read the diff yourself.

@anton_zaporozhets1 Of course Open Wearables will propagate error (I suggest to use something like sentry to catch such exceptions), but you will still be able to connect with other providers, even if you will have broken connection with Garmin.

And I understand your concenr. In 2024 (or event 2025, don't remember) Garmin switched from OAuth v1 to Oauth v2 for example. It's a big change, but they didn't remove old endpoints which based on old OAuth standsrd. Of course it wasn't documented after the update to not tempt new users to use this.

@mwarcholinski Thanks! Open Wearables is rather B2B product but with a little bit of Claude support you should be able to run it locally as everything is dockerized and shouldn't take more than few minutes or use one-click Railway deployment to set up your own instance in cloud. Then you could also use the MCP server to talk your apple health data and get the feedback you need 😄

@mwarcholinski As Piotr said, it's B2B, but you can still use cloud based providers as a private user (by cloud based I mean Apple, Samsung & Google).

@mwarcholinski that's exactly where we're going with the AI layer - you ask a question in plain language, you get a real answer based on your actual data

not there yet for non-technical users out of the box, but it's the direction. watch this space

@zerotox The Stripe analogy fits the data layer well:) Where we go further is that Stripe stops at the transaction: we also compute what the data means, with open algorithms you can audit and tune. Health intelligence on top of the plumbing, not just the plumbing.

@zerotox Interesting take, thank you for your kind words!

@zerotox we will be using that slogan more often! :D

@syed_shayanur_rahman Thanks. Developer-first was a deliberate call: if the foundation isn't solid and transparent, everything built on top is fragile.

@syed_shayanur_rahman That's an honor to hear that, thanks!

@roopreddy Batch-based right now, which reflects the underlying provider APIs: most wearables sync to their cloud on a schedule rather than streaming continuously. Some providers like Whoop expose webhooks, and we're looking at event-driven support for those. True real-time would require lower-level device access that most providers don't offer yet.

@roopreddy Thanks! This depends also on the providers how often they push data but as soon as these data reaches Open Wearables, there are webhooks you can use to push data to your backend real-time - here is more info about it: https://openwearables.io/docs/api-reference/guides/webhooks#outgoing-webhooks-open-wearables

@roopreddy To not repeat afer other, I can tell that FIT files supports is also planned, so it can changed how we fetch data to Open Wearables.

@himani_sah1 It is early days, and we're upfront about that. The use cases already showing up are the interesting part: clinical teams auditing algorithms, coaches normalizing HRV across devices, AI builders wiring the MCP server into health coaching tools. We'll be watching what gets built.

@himani_sah1 Early days, yeah - but it's already a full engine :D

@himani_sah1 that's true, but we ship fast. Open source is an incredible force, especially when it comes to community. :)

@jakub_mitka  I’m looking at it in a similar way, something to evaluate on the next relevant project 👍

Nice to see someone from Krakow thinking about it in a client context too. It feels like this could genuinely simplify working with health data, if it delivers on the promise. I’ve also come across the Momentum team before - good to hear they already have a solid track record in

@jakub_mitka Jakub - appreciate the vouch. Product studios with multiple health clients are honestly the cleanest fit for this - one shared layer beats rebuilding integrations for every project.

@jakub_mitka Love to see this added to the studio toolkit! Having a unified API ready to roll out for future health clients is a massive time-saver for agencies. Greetings to Krakow! 👋 And I completely agree-the Momentum team has definitely earned their strong reputation in the healthtech space.

@kohnigel Thanks Nigel! That's the bet, the moment "ask Claude about my sleep last week" becomes one click instead of a CSV export, the whole consumer health workflow shifts. MCP is the entry point, but the real unlock is agentic: long-running assistants that watch your trends, flag anomalies, and reason across weeks of data without you prompting. Still early days, but the direction feels right.

@kohnigel Indeed, but rememember - at the moment our MCP is still not 100% production ready.

@kohnigel Spot on! Bridging the gap between messy wearable data and mainstream LLMs is exactly where the magic happens

@raihanshezanPlugs directly. Our MCP server gives any LLM (Claude, GPT, local via Ollama) structured access to user health data with context, scores, trends, anomalies, so you're not dumping raw numbers into a prompt. If you'd rather wire it into your own pipeline, the REST API works the same way.

For production-grade use cases (coaching, clinical reasoning, longitudinal context), an agentic layer on top earns its keep fast. We build that at Momentum for clients and might share some templates soon, stay tuned.

@raihanshezan You can use backend API to achieve that. In the future there will be also an AI agent.

@jacksonburch Breathing + HRV + respiratory rate is a nice fit for the data model, all three are surfaced across most providers (Garmin, Oura, Whoop especially). If you give it a spin, drop into Discord with whatever you find tricky, happy to help unblock. Good luck with TryBreathing.

@jacksonburch Jackson - group breathing with live biometrics is genuinely one of the more interesting use cases I've heard today. The latency tradeoffs across providers are real (some are near-real-time, others poll on

intervals) - Piotr or our infra folks can dig into the specifics on Discord. Either way, that sister site sounds like exactly the kind of thing this stack was built for.

@istiakahmad Thanks Istiak, appreciate it. The healthtech space especially needs more open infra: too much critical patient data sitting behind closed APIs and per-user fees.

@istiakahmad Yeah, open source with the great care for software quality is what we really need in the age of AI.

@istiakahmad 

Couldn't agree more! Having open infrastructure instead of walled gardens is exacly what this space needs to move faster. Love seeing this trend!

@viveka7 Hey Viveka,

Orchestrating multiple AI models is genius, but explaining that complexity to drive sales is a different challenge.

My superpower is turning complex tech into landing pages that convert.

I'd love to show you how small UX tweaks to your current page could turn lookers into buyers.

Free 5-min chat?

@jocky That’s exactly the shift we’re aiming for.

Less about talking to individual AIs, more about setting direction and letting the system carry things forward.

@jocky Thanks for the support!

That's exactly the vision — you become Tony Stark, and KarmaBox becomes your JARVIS.

@jocky Less about figuring out every step, more about setting the goal and letting the system handle the rest.

@elijahbowlby That’s exactly the use case we had in mind 🙌

It’s not really tied to a single session. Once you kick off a task, it keeps running in the background across your devices.

So you can start something on your laptop, close it, and pick it up from your phone later — the system just keeps progressing.

@elijahbowlby For longer tasks, it’s more like ongoing execution:
things keep moving, results sync back, and you can jump in whenever you want.

@elijahbowlby 
This is a simple copywriting task, no tools needed.
KarmaBox handles both:

Long-running tasks: We queue them and run them in the background on your devices. You get notified when complete.

Real-time sessions: For interactive work (like coding), you can maintain live sessions and check in anytime.

Perfect for your commute use case — kick off a task on the train, and KarmaBox keeps working while you're offline. Results waiting when you check back!

@xavier_hernandez2 Haha appreciate it 🙌 Typiest is very real 😄

You don’t need a beefy phone. The phone is mainly the control center — sending tasks, monitoring, and continuing workflows.

The actual heavy lifting runs across your other devices (laptop, workstation, servers, etc.), so even an older phone works fine.

@xavier_hernandez2 KarmaBox is designed to be lightweight. It works on most modern smartphones

@boyuan_deng1 
KarmaBox continuously monitors device status (online/offline, battery, load). When routing tasks, it only uses available devices:

The system is designed to be resilient — devices can come and go without breaking anything.

@boyuan_deng1 Great question — and thanks!

It doesn’t require all devices to be online. We separate compute and state:

• Compute is stateless (VPS / sandbox / laptop), so tasks can run on whatever is available.

• State is persisted separately, so progress isn’t tied to any single machine.

If a device goes offline or runs low on battery, the system just routes work to others. No need for the whole pool to stay active.

@boyuan_deng1 Thanks 🙏 — and good question, because this is where the design choice actually matters.you're asking about the KarmaBox pool — the machines you've connected (laptop, desktop, home server, etc.).

Heartbeat-based registry. Each KarmaBox keeps a lightweight WebSocket to Server announcing state — online/idle, online/busy, offline (last-seen timestamp), plus power state (plugged in / on battery / low

battery). Server's machine pool is a live view of who's available right now.

@achuth_noob Great question! Claude Remote Control lets you run Claude Code on a remote machine — it's essentially a terminal in the cloud. Karma goes further in a few key ways:

1. Mobile-native, not mobile-adapted

Karma is built from the ground up for your phone. Full conversation history, streaming responses, tool call visualization, voice input — all designed as a mobile-first experience, not a ported terminal.

2. Your machine, your data

Karma runs on your KarmaBox (Mac/Linux). The AI executes on hardware you own. E2E encrypted. Nothing goes through Anthropic's servers except the LLM call itself.

3. Persistent AI teammates, not sessions

Avatars with skills, memory, and personalities that persist across conversations. Think less "remote terminal" and more "AI coworker you can reach from your phone at 2am."

4. Orchestration layer

Multi-agent coordination, skill marketplace, project-level context — built for teams running parallel workstreams, not just a single dev querying Claude.

In short: Claude Remote Control is a power tool. Karma is the operating system around it.

@achuth_noob Great question — and excited for you to try it out 🙌

Claude’s Remote Control is mainly about accessing and running Claude across devices.

KarmaBox is a bit different — it’s not tied to a single model or a single machine.

It coordinates multiple models and agents, runs them across all your devices as one system, and keeps tasks moving even if you step away or switch devices.

So instead of controlling one AI remotely, you’re essentially running a whole system of them together.

@abod_rehman Great question — this is actually a core part of how KarmaBox works.

It’s not just rule-based. We use a routing layer that looks at the task context and decides which model, agent, and even which device should handle each part.

Think of it less like fixed rules, and more like a system that’s continuously choosing the best path for the job.

Still evolving, of course — would love to hear how you’re currently handling routing on your side 👀

@itsluo Love hearing that — that shift is exactly what we were aiming for.

Once things start running in parallel, it really changes how you approach work altogether.

@itsluo Thanks so much for the support!

You've hit the nail on the head — parallel execution is exactly what we set out to solve. Instead of waiting for one AI task to finish before starting the next, KarmaBox lets multiple agents work simultaneously on your device.

@fletcher_oliver Haha great question 😄

One thing that surprised us was how quickly agents started coordinating on their own.

We’d kick off a task expecting a linear flow, and instead multiple agents would split it up, share context, and converge on a result way faster than we planned.

It wasn’t something we explicitly scripted — more like the system figuring out a better way to get things done.

@fletcher_oliver Curious what kind of “weird” behavior you’d want to see from a system like this? Haha~~

@antonio_manuel1 Totally feel that — it adds up fast.

@antonio_manuel1 KarmaBox doesn’t auto-log into everything, but once you connect your models/services, everything runs through one system.

So you’re not jumping between tools or re-authing every time.

@antonio_manuel1  Thanks 🙏 — this is one of the pain points that motivated the whole thing, so let me be specific.

Short answer: yes — connect once, never log in again.

Karma handles AI provider access entirely. Use the energy wallet — no separate ChatGPT / Claude / Gemini accounts to log into at all. One Karma login, all the models. Most users land here.

@barnaby_lloyd Appreciate it 🙌 great question.

@barnaby_lloyd Running 24/7 doesn’t mean it’s constantly burning tokens — agents are mostly event-driven and only call APIs when there’s actual work to do.

On top of that, we route tasks across different models depending on the job, so you’re not always hitting the most expensive one.

Since compute runs on your own devices, you also avoid a lot of the infra cost you’d normally have.

So it’s pretty controllable in practice — and we’re adding more knobs for users to tune cost vs quality as well.

@barnaby_lloyd Thanks 🙏

To answer at the layer beneath the user-facing controls — because the cost story is partly about routing, but mostly about what we run behind the routing.

Aggregated LLM credit pool. Karma negotiates volume rates across Anthropic / OpenAI / Gemini / Qwen / DeepSeek and pools usage across our user base. That's 20–40% better unit economics than any individual

user gets on direct API. Variance gets absorbed by the pool — you don't feel the spikes, and the energy unit stays stable across vendor pricing changes.

Aggregated cloud execution pool. Sandbox runtimes (E2B), VPS-class compute, GPU resources for image/video — all warm-pooled with second-scale provisioning. No cold-start tax billed to your task, no per-VM

rental on your account. When an avatar fans out to a sandbox or spins up a longer container, the capacity is already there.

This is what lets routing stay quality-neutral. If we were a thin passthrough, every "Sonnet not Opus" call would be a quality-vs-cost tradeoff for the user. Because the backend is pooled, routing optimizes

against pool economics — you still get the right model for the task; the savings come from infrastructure leverage, not from downgrading your output.

@visualpharm Great question — but I’d push back on “Opus for everything.”

Arena ≠ real workloads. It measures chat quality, but real usage involves latency, agent loops, tool calls, long context, etc.

A few quick points:

• Latency matters — slower models hurt UX in interactive flows

• Different strengths — coding, reasoning, classification, multimodal all favor different models

• Blended routing wins — fast model for most tasks, stronger model when needed

In practice, one model rarely wins everything.

That’s why KarmaBox is model-agnostic with routing built in — so each task gets the right model automatically.

Curious how you’re choosing models in your setup today?

@cynthia220 That’s such a real one.

A lot of the fatigue isn’t the work itself — it’s constantly checking and nudging things forward.

Once that goes away, the whole experience feels a lot lighter.

@shirleyw Thanks — really appreciate that!

We were aiming to do something a bit different from the usual AI tools.

@janicelewis00 Exactly — once you've experienced parallel AI execution, single-thread feels like using a flip phone. There's no going back!

@janicelewis00 Totally — that switch from step-by-step to parallel is hard to unsee.

Once multiple agents are working at the same time, the old “wait → next step → wait” flow just feels slow.

@tijogaucher Heavy AI compute runs in the cloud (Claude, Gemini, etc.), while your device handles lightweight orchestration — so minimal battery/thermal impact. You can also set battery limits and pause tasks when needed.

@tijogaucher Haha yeah — definitely not melting your phone 😄

@tijogaucher The phone is mainly the control layer, not where the heavy work runs.

Actual execution happens across your other devices (laptop, workstation, servers, etc.). The phone just lets you trigger, monitor, and continue tasks.

So battery/thermal impact on the phone is minimal — it’s closer to “remote control + command center” than on-device execution.

@shaowei1 Exactly — that hidden waiting time adds up more than people expect.

Once things run in parallel, you stop thinking in “steps” and start thinking in outcomes.

Curious what kind of workflows you felt this the most in?

@shaowei1 That's the hidden cost of sequential AI — KarmaBox reclaims all that lost time by running everything in parallel.

@satish_autade Hey — really appreciate that, and totally hear you on the multi-agent pain 🙌

Right now the app is only available on the App Store in North America and Singapore while we’re rolling things out gradually.

If you’re open to it, we can add you to our early access list for the next regions — happy to get you in as soon as it’s available 👍

@satish_autade Out of curiosity, which country are you based in?

@yan_labs_ Exactly — that’s been our experience too.

@yan_labs_ Once you see things happening in parallel, the old step-by-step flow starts to feel really constrained.

@wenjun_shi That’s exactly the shift we’re going for 🙌

@wenjun_shi Less about figuring out every step, more about setting the goal and letting the system handle the rest.

@wenjun_shi  Thanks 🙏 — that's actually the entire design thesis in one sentence.

Most AI tools still make you carry the how: pick the right model, write the right prompt, chain the right tools, manage the context, remember what you said last time. The load just shifts from doing the

work to operating the AI.

@bengeekly Personalization is core to how we built Gro — every message is generated based on the lead's recent activity, profile context, and the specific signal that triggered the outreach, so it's never a static template. You can also set tone preferences and voice guidelines per campaign to keep things on-brand.

@leah_leee Honestly, not at this current moment but we are working to bring integrations to our users for this new feature so that you can do exactly what you asked. Thanks for the question!

@jaredl thank you and that's great to know! please try it and let us know how you fare/if you have any questions.

@doriiiiis_ Thanks for the question! Our monitoring function is currently set at 12 hours periodically, i.e. if you initiate a social signal monitor at 08:00, the scan would activate at 20:00, and so on.

@osakasaul Hi Saul, great question. Yes, you get context (i.e. the whole post) when you go deeper into the social signal analysis.

Here are the credit rates for various actions:

• Per search: 2

• Import: 2

• Email enrichment: 2

• Profile enrichment: 2

• Buying intent analysis: 1

• Propensity analysis: 5

Our monthly credit offerings for the tiers ranges from 2000-10,000.

@jiaqichen Yes! We have a freemium tier with 100 credits that includes people search, Social CRM (data enrichment + lead import), propensity analysis, and social signal analysis. Each action uses credits, so you can play around with the core workflow before deciding if you want to upgrade. Plenty to test the waters as a solo founder.

@nazarenko That’s a very real problem and honestly, what you described (F5Bot + manual scrolling) is exactly how most people start before it becomes unmanageable. You’ve already nailed the core issue: keyword monitoring breaks because it treats every mention = intent, when in reality most of it is just noise. Using F5Bot + LinkedIn manually gives you coverage, but not interpretation.

Gro balances this out with 1. context (i.e. surrounding phrases, role, company, type of sentence etc.) so it's closer to answering the question of "is this person likely to be in a buying mindset?", and 2. multi-signal layering, for example.

• mentions “translation”

• recently hired localization team

• works in a scaling SaaS company

Much higher confidence vs just a random post.

@indigo_carpiniello Appreciate it! Quick clarification on how it works today: Content Search is a one-shot keyword search across posts, so with the right phrases ("frustrated with [competitor]," "looking for alternatives to X," etc.) you can absolutely surface negative-signal posts right now. What we don't have yet is a "monitor this search query" function. Today monitoring runs at the author level (track future posts from authors you've saved). Continuous monitoring on a search query is on our roadmap:)

@german_merlo1 Thank you! Appreciate the comment, please give it a shot and let us know how you fare.

@peyton_perez Thanks for the question, Peyton. Our main focus is very much finding the right intent signals within a reasonable amount of time for our users to get the messaging right. At the moment, the refresh is every 12 hours, and once found within the most updated cycle, any programmed flow would trigger.

@asher_luca Thanks for the question! Gro mainly differs on the following: insight to action gap

Sales Nav gives you a reason to reach out but you still have to:

• decide who to prioritize

• write the message

• run the sequence

while Gro goes from signal → targeting → messaging → outreach (LinkedIn + email) in one flow.

and then there is Individual alerts vs system-level orchestration:

• Sales Nav is very seller-driven (you interpret + act)

• Gro is more system-driven (it suggests + executes at scale)

@philip_kubinski 
Short answer: you’re not locked in.

We are in the midst of building Gro to work both ways depending on how you like to run outbound:

1) Use Gro end-to-end (currently the status quo)
Most users just run everything inside — from discovery → scoring → LinkedIn/email outreach — mainly because the data stays “live” (intent signals, enrichment, engagement all in one loop).

2) Plug into your existing stack (we currently have hubspot, and working on webhook)
Soon, you can absolutely push leads out:

• Export or sync enriched + scored leads

• Trigger via webhooks into your sequencer

• Use Gro more as the “thinking + targeting layer” on top of your stack

Where we’re opinionated is this: Most workflows break when you export static lists too early. The moment leads leave, you lose intent freshness + adaptive targeting; which is why a lot of Clay-style setups need constant re-refreshing.

So it’s less “you have to send through Gro” and more:
→ If you want maximum performance, keep it in one loop
→ If you want flexibility, we are working to allow you plugging into your stack just fine

Are you mostly running cold email via Instantly, or doing LinkedIn + email in parallel? That usually changes how people set it up

@th_calafatidis Thanks so much! Totally agree, sales is often the difference between a great product getting adopted and a great product getting overlooked. Glad Gro can help level the playing field, especially for small teams who don't have a full sales org behind them.

@daniel_harris11 At the moment, we're focused on keywords and the mission is to reduce noise enough so that the signals are useful at scale. We weight signals (e.g. hiring, tech changes, engagement patterns) and look at combinations, not just single events for our scoring analysis.

Instead of just “X happened → notify you”, Gro is also constantly re-scoring accounts based on:

• recency

• frequency

• ICP fit

@madalina_barbu Thanks, pls give it a shot.

@yan_labs_  Love this question. Today, signals are surfaced at the individual author level, but account-level aggregation is something we're actively designing, exactly the scenario you described ("multiple people at one company posting about the same topic in a given window"). It's a much stronger buying signal and pairs naturally with ABM workflows. Would love to keep you posted when it ships.

@nah_na Yes. In our Custom Guidelines field, you can paste in a few of your past messages as reference and instruct Gro to mirror that style, things like sentence length, opening style, and word choice. It's a simple way to get the voice closer to yours from day one.

@josie_oy Great question! A/B testing isn't live yet, but it's high on our roadmap, being able to compare angles per signal type is exactly the kind of feedback loop we want to build in. For now, users typically run parallel campaigns with different message angles.

@eexlkuang_se Great question. As many as your credit allowance can handle

@boyuan_deng1 Thanks for the great question and you’re right, mid-market SaaS is exactly where most tools start to break down. From what we’ve seen running campaigns (and building Gro around that), the issue isn’t top-of-funnel coverage, most tools can give you thousands of contacts. The gap shows up in relevant coverage:

• In typical outbound tools, you might get broad account coverage, but only a small % are actually active or in-market

• That’s why you see ~3% connect rates and ~1% replies in standard workflows

For mid-market SaaS specifically, what tends to work better is signal-based coverage vs static lists:

• Instead of “we have X% of companies in your ICP,”

• it becomes “we’re tracking the subset of accounts showing intent right now”

With Gro, coverage is less about database size and more about how many high-intent accounts you can actually engage at a given moment which is why campaigns tend to land closer to ~28–30% connect and ~10% reply rates when targeting is tight

So short answer:
Mid-market coverage isn’t the bottleneck anymore, precision within that coverage is. That’s where most tools fall short (and where we’ve focused heavily).

@abod_rehman Thanks for the question! It's real time and we're always looking for new data sources to connect.

@3rdmatter Yes you can, we have laid out the options for users to choose mainly for the campaign.

@sunaina_ukil1 I'm glad it's resonating with you!

@thisiskp_ "Even our AI agent literally cannot modify production"

Music to the ears of anyone who's had their database emptied by an agent by accident.

2 minutes to try it out? I'll take you up on that offer!

@avrisimon thank you so much for the kind words. Great to hear the core problem we’re tackling here resonates with you closely.

@gabriel_brooks1 100% - I was doing a lot of testing with Agent runners and knowing every single run across multiple runs had an isolated state to test whatever it needed to inside of was a huge relief!

@kunal_s1 that Slack message is universal haha. Thanks for trying this out. Let us know how your builds go!

@ashamplifies We wouldn't be Netlify with you people like you in our community Ash 🤝

@ashamplifies thanks for the warm compliments. "build on a secure and strong foundation of infrastructure with new releases that always feel production ready" -> that is exactly how we view product development internally. Solid infra that can scale from side projects to world class brands.

@evan_sterling Trying to figure out how you're going to mock up data in an empty branching database and make sure it translates backwards for your merge was always a key hassle of wiring one up. Stoked to keep making that experience even better 🫡

@nikita_shamgunov Thanks for ALL the support Nikita! Great things on the horizon

@gabriel_brooks1 well summarized - thank you

@mahdi_nouri hey man! How are you? Thanks for the Q.

Netlify Database's disaster recovery approach is built around reducing blast radius and fast recovery: most changes happen in isolated database branches (deploy previews / agent runs), not directly on production.⁠

⁠⁠

⁠

Before publishing a production deploy, we take a snapshot of the production database so you have a restore point if something goes wrong (retention varies by plan).

@nat_lasica great work on the launch Nat!

@robert_hilscher and you were a huge driver behind this release. Great work Rob, you should be extremely proud!

@robert_hilscher great job, man, you da best!

@robert_hilscher huge part in making this happen. Great work and I'm looking forward to future releases!

@danshipit Thanks Daniil! Great question.

From what we've seen, it's great for quick drafts, but there are gaps when it comes to real workflows.

The biggest one is design systems. It approximates them rather than using actual components, which leads to drift in fonts, spacing, and colors. Also, every edit costs credits - even small tweaks like moving an element.

Forge works directly with your components, so what you generate stays consistent. And you can edit manually without burning tokens on trivial changes.

@nat_lasica  @abhiranjan_mehta Short answer: no, because the architecture prevents it.

Claude Design reads your codebase and generates new elements styled to match. That's approximation - and approximation drifts. Wrong fonts, incorrect colours, inconsistent spacing. We heard the same from dozens of people just this week.

Forge works differently. Your component library syncs from Git into UXPin meaning Forge can only use components that exist in your library. It can't generate a button variant you haven't defined. It can't invent a card style that isn't in your system. Off-brand output isn't something you catch in review, it's structurally impossible.

On top of that, you can set Design System Guidelines: plain-text rules that constrain all AI output. Things like "primary buttons only in the main CTA position" or "cards always use 16px padding." Every team member, every generation, same rules.

Try it with one of the built-in libraries (MUI, shadcn) and you'll see the difference in the first prompt.

@chase_horn you could always start a trial, prompt something you want and then hit 'get code' and find out 😉

Here is an example output straight from a prototype;

import Button from ‘@mui/material/Button’;
import Card from ‘@mui/material/Card’;
import TextField from ‘@mui/material/TextField’;
import Typography from ‘@mui/material/Typography’;

<Card >
     <CardContent>
          <Typography variant=”h5″>Create Account</Typography>
          <TextField label=”Full Name” variant=”outlined” fullWidth />
          <TextField label=”Email Address” type=”email” fullWidth />
          <Button variant=”contained” fullWidth>Sign Up</Button>
     </CardContent>
</Card>

@chase_horn VERY clean ...

@uxpinjack some great example use cases for anyone keen to test it out!

@sonu38 Yeah, the gap is usually in implementation. Most tools get close visually but devs rebuild anyway. With Forge you start with real components instead of mockups.

Give it a try, curious to hear how it works for you!

@sonu38 i feel like we got really close to closing the gap way back when we released Merge. With Forge we are introducing AI and combining it with Merge technology to speed up the process.. all while ensuring the designers maintain complete control and can manually iterate whenever they want.

@sneas thanks Dimah! Looking forward to your feedback

@thomas_dupuy2 you sure can!

You can ask it to replicate the URL so you can have an editable UI to work with, or you can use a URL for inspiration for your own design.

@thomas_dupuy2 You can see it in action here: https://focusee.imobie.com/share/14013b5c6d15448698b2f7fe26ff0cca

@sriya_vipin thanks Sriya!

@julia_prus1 thanks!!

@julia_prus1 Thanks! It's been a fun road

@luke_marshall4 It not only helps with design decisions, but also helps teams move onto a real coded component foundation so they can start shipping faster.

With global libraries like MUI, shadcn/ui, or Ant Design, Forge maps your brand and design language onto existing production-grade components. From there, it generates layouts using those real components and outputs production-ready code out of the box.

@luke_marshall4 Jack nailed it with his response. You can also use the global libraries and create your own themes for different projects

@jolina_teniedo That's the whole point! AI should be constrained to your system, not freestyling. Glad it landed, let us know how you get on with it.

@teri_morgan2 That's because most of them generate to their own conventions. The output looks great in the demo. Then you try to use it with your actual components and it falls apart.

We took the opposite approach wehn building Forge - it starts from your components. The AI is constrained to what exists in your synced library, so the output works from the first generation, not after hours of fixing.

Curious what broke for you specifically? Happy to show how Forge handles the same scenario.

@ethel_aranjuez there sure is. We have a free trial of 14 days which can be extended by a further 7 days by booking a demo with our team.

@adam_tornhill_cs Really resonates. MCP flips this from insight → action.

Instead of just knowing where technical debt is, teams can now operationalize it in real-time workflows, prioritizing hotspots, guiding AI agents, and preventing bad code from scaling.

AI doesn’t just need code. It needs context. That’s where MCP becomes a force multiplier.

@adam_tornhill_cs instructing an agent is hard enough trying to do it in a messy codebase is impossible. CodeHealth MCP feels like 'cleaning up the room' before you ask a guest to come over. Makes the agent way more effective. Congrats on the ship!

@adam_tornhill_cs AI speeds everything up, including mistakes.

If code health is bad, AI just spreads that mess faster so tracking and feeding code quality into the workflow becomes essential, not optional.

@avrisimon You can instruct AI to self-correct by having instructions in your generic `AGENTS.md` or `CLAUDE.md` file (depending on agent), which the agent will read as sort of a global context. We have an example `AGENTS.md` file in our repository here if you want to take a look: https://github.com/codescene-oss/codescene-mcp-server/blob/main/AGENTS.md.

The number of iterations it needs to do to achieve healthy code depends on a few factors, so it's hard to give a concrete number. How bad is the code? The worse the code is, the harder it will be for AI to one-shot the solution. How good is the AI model you use? The better the model, the better it can understand instructions given by the CodeHealth MCP. In general though, with the latest Opus models from Claude and with code health even as low as 2 out of 10, I've personally seen it able to get to 10 out of 10 in just 2 iterations.

The MCP is also great at safeguarding already healthy code so that AI can't start introducing subtle defects or code smells into your code. This is important because healthy code requires a lot less tokens to understand and you need to spend no tokens at all on refactoring, saving you money.

Does that answer your question?

@avrisimon Great point, and that scaling experience really puts the problem in perspective

@lht8 "Works but nobody should touch this", we've all shipped that code🙈, and it's even easier to do when the AI is moving fast for you. Really glad the health scoring gives you something concrete to aim at rather than just vibes-based cleanup. Thanks for being a CodeScene user and for jumping on this so quickly 🙌

@lht8 Thanks for that lovely feedback, Marcus. Supper happy to hear that!

having real-time CodeHealth feedback baked directly into my AI coding assistant is a game changer. It catches the kind of subtle technical debt that accumulates fast when you're moving quickly

This is so important. An AI won't write "good enough" code on its own. In fact, we find that agents often operate in a kind of self-harm mode. They generate code that is inherently incompatible with, well, themselves. (A strange paradox).

With the CodeHealth MCP, we safeguard all code. It's the tool that enabled me and my team to go fully agentic. And we're not looking back 😊

Thanks@lht8 , much appreciated!

@tajib_smajlovic Thank you so much for your support, our team appreciates it a lot. How reliable has AI-generated code been for you in production so far?

@tajib_smajlovic I'm glad you like the product!

@tajib_smajlovic Great to hear Tajib! Looking forward to hearing your thoughts on the MCP 🙏

@ben_gend Yes, those are first class citizens in the Code Health score. Functions doing too many things are caught as Brain Methods, a dedicated metric for complex functions that centralize too much behavior. Classes that have grown beyond reasonable scope show up as Brain Classes (large modules with too many responsibilities) or Low Cohesion, which specifically measures whether a class has multiple unrelated responsibilities breaking the Single Responsibility Principle.
There's also Bumpy Road, which catches functions with multiple dispersed chunks of logic that should have been extracted into their own functions.

You can read more about our Code health metric here: https://codescene.io/docs/guides/technical/code-health.html#code-health-identifies-factors-known-to-impact-maintenance-costs-and-delivery-risks

@ben_gend Yeah, "did I just create six months of tech debt in 20 minutes" is really worrying as many developers don't even think about this impact. The see the larger commits but their current task was solved...

Thanks for your question@ben_gend CodeScene looks at some 25 different roles that drives complexity. You can read more about some of the smells here (https://docs.enterprise.codescene.io/latest/guides/technical/code-health.html#module-smells)

@johan_nordberg Thanks a lot for your feedback!

I also use the MCP server to ask about code that I might think is too complex, or where I sense something is wrong, but can't really put words on it. The MCP is so good at evaluating the code quality and give suggestions for improvements.

I like that. It's a really important aspect of going agentic. Our research finds that AI requires even better code quality than humans, not less. The CodeHealth MCP allows us to pull that risk forward, and strategically refactor code to make it AI-ready.

@johan_nordberg Couldn't agree more on the amplification effect, it's probably the most underrated risk in AI-assisted development right now.

@askonmm Totally agree, it's underrated. The "asking an LLM if LLM code is good" loop has some obvious blind spots.

@tadej_kosovel Deterministic is the only way in the world of non-deterministic AI, I think.

The scoring model looks at many things; module smells, function smells and implementation smells. Part of those are things such as cyclomatic complexity and coupling indeed, but there's a whole lot more that goes on, and we keep continuously improving that metric as we go along. You can read more specific info on the CodeHealth metric here: https://codescene.io/docs/guides/technical/code-health.html#code-health-identifies-factors-known-to-impact-maintenance-costs-and-delivery-risks.

Does that help answer your question?

@tadej_kosovel Agree 100%. We really believe on deterministic quality signals is key for the current LLMs.

@conduit_design It's CodeScene analysis tools as an MCP, which works in the same space as SonarQube. It can help you do code health reviews, uplifting of unhealthy code and safeguarding AI generated code. Is there a specific use case you're interested in?

@conduit_design Thanks and lot, André!

CodeScene's MCP is based on the Code Health metric. It's the only validated code-level metric with a proven impact in terms of faster (shorter lead times) and better (fewer defects).

Compared to linting aggregators like SonarQube, Code Health works at a higher level. Think of linters like the line-by-line commenting whereas Code Health checks the design and structure of the code to guide agents.

Does that help explaining the difference?

@odeth_negapatan1 Thank you, Odeth!

It's important to have checks that verify AI created code. You could have unit tests in place and instruct AI to make sure that tests pass. You could instruct AI to always check that test coverage is a high percentage (at CodeScene we try to aim for 95%+), this way AI can deterministically check if tests cover the logic it created or not. Finally you could have our CodeHealth MCP which can check for code quality issues, degradations, do uplifting and safeguarding.

Does this help answer your question?

Thanks odeth_negapatan1 you should try it out!

@odeth_negapatan1 

Thank you Odeth, really appreciate your kind words and looking forward to hearing your thoughts when you have tried it out :)

@johan_martinssonInteresting point about micromanaging, it actually help you with that.

@johan_martinsson1 Thank you! We think the CodeHealth MCP is the missing link in agentic programming. You should definitely give it a go!

@johan_martinsson1 Not having to micromanage quality is exactly the goal, agents should self-correct, not wait for a human to notice the mess

@mrksbrg Indeed! I'm excited for how far we can take this, and what other tools we could create to further improve software quality.

Insightful! @mrksbrg 

@mrksbrg That's good news and I'm glad to hear that it's picked up as an important theme :)

@freyawi We're glad you like it! If you have any feedback on how we could improve things further, we're all ears.

@freyawi Great to hear Freya 🙂

Thank you@freyawi I'm glad to hear!

@fredrik_ekstrand Indeed! What I like best is that the MCP takes away the pain of cleaning up poor AI generated code and allows me to do my work in a more holistic way, thus allowing me to achieve more, not only in velocity, but also in breath. I no longer think in terms of code, but in terms of architectural specs, and it's been liberating to me as a generalist.

@elijahbowlby It works as both. You can use it to review code health on demand (code_health_review tool), for before committing (pre_commit_code_health_safeguard tool) and also before pushing (analyze_change_set tool). If you add instructions to your generic agents instructions file, it can do it on its own. An example `AGENTS.md` file is also available in our GitHub repository, here: https://github.com/codescene-oss/codescene-mcp-server/blob/main/docs/AGENTS-standalone.md.

Internally we use it during development to maintain perfect code quality, but also as a last step safety check before pushing our changes.

Does this help answer your question?

@elijahbowlby The cool thing is that the CodeHealth MCP becomes part of that inner agentic developer loop, catching any slip in maintainability early. Claude Code then self-corrects, refactors the offending code, and re-evaluates with the MCP.

I’ve used the MCP internally during development, and its safeguards kick in during virtually every coding session. That also saves a lot of tokens going forward.

@romanela_p The built-in ROI calculation is powerful. Refactoring might be a hard sell to a PO/PM who's busy with new features. The ROI calculation puts a business value on refactoring.

And yes, it's based on CodeScene's peer-reviewed research where we developed a statistical model for translating Code Health deltas into business impact: faster and/or better.

@romanela_p One of the shortcomings of many engineers is that they struggle with quantifying important engineering aspects into business impact and thus often fail to convince their managers to green light some important refactoring work. The CodeHealth MCP's code_health_refactoring_business_case tool solves that problem entirely.

@stefan_persson1 Everybody has a different development flow, of course, but I personally use it something like this: I create an initial prompt to the AI to work on some task. I've instructed it via `AGENTS.md` to always run code health review after every change, and if it has degraded, fix it on its own. This allows me to focus on the task and not the code quality, which the CodeHealth MCP takes care of. Once I'm done with my task I run the `analyze_change_set` tool to make sure that my feature branch doesn't have any degradation's compared to the master branch, and if there are, I will ask AI to fix those issues using CodeHealth MCP guidance.

This makes sure that the code itself is of perfect quality, but of course it can't understand architectural choices, so the very last review is still made by me - a human - to verify that everything looks good. I can focus on architectural analysis, and no longer have to focus on tedious code health parts, which is very liberating.

@alwaysunday Feels less like a dashboard tool and more like a layer that actually understands your business logic. Packaging data, rules, and visualization into “Skills” is a smart way to avoid the usual BI setup mess. If it works as described, going from Supabase to production-ready dashboards without ETL or tracking could save a lot of time. How flexible are these Skills when business logic evolves or gets more complex?

@atomicimagery You can import images from the Assets tab, ask Claude to find and download images from the web (and save them), or if Claude has access to your codebase, he can import them directly as well :)

@rajinder1 Thanks for the empathy — I’m going to dig deeper into exactly that pain point 🙌

@mrbrjan “Scroll capture” is a feature that lets you turn long, scrollable content into a single image — feel free to check it out: https://snapr.pineple.com/guide/pro/capture-scroll

Also, does “scroll capture” sound natural to you? I’m not a native speaker, so I’d really appreciate your feedback.

@thomas_berg3 That’s a great point — I’ll definitely think more about lowering the barrier to entry.
Snapr actually offers a 7-day Pro trial as well, so feel free to give it a try 🙂

https://snapr.pineple.com/trial

Thanks a lot for the feedback!

@sandeep_gadher I’m more of a “hot-headed builder” than a logical one, but I like the way you put it — “a logical step” sounds much nicer. Thanks!

@ritu21 I’ll do my best to make that happen — one advantage of being a solo builder is I can move pretty fast 😄

@robert_douglass No a dictionary would be too brittle, it uses a combination of tools.

Presidio handles regex-based PII (IBAN, email, tax IDs). For names, we use three NER models, all local:

• The NER component of spaCy's de_core_news_lg pipeline (called via Presidio)

• Flair's de-ner-large (dedicated NER model, separate pass — catches "Schmidt, Lisa" comma-form and lowercase legal text)

• GLiNER (zero-shot — add custom entity types at runtime without retraining)

Each NER fails differently, so the three vote together, because the union has better recall than any single one.

@elijahbowlby Honest answer: it will not be invisible on 10K-line files with the full pipeline. Flair's the bottleneck here. For huge logs you can drop Flair and run Presidio + spaCy only — ~10× faster, you lose some German name recall but the regex layer still catches IBANs and emails (which is the actual fintech failure mode).

The hook is async, so Claude Code shows a "redacting…" state instead of blocking. But yeah — for large files, you will feel the latency!

@zabbar Not yet, but we have it on the roadmap!

@elenagoldberg Love the concept behind Factory turning founder context into an investor-ready strategy doc in minutes. That immediate, structured output is powerful, but that first impression has to convert browsers into paying users.

A few small optimizations to your landing page copy and flow could help turn more of that traffic from Product Hunt into customers. Would you be interested in seeing a few specific ideas?

AI Wrapper.

@elenagoldberg great job, I need this exactly now!

Finally out!

Been a crazy journey taking this from a rough idea to something people are actually using today.

We’ve spent a lot of time trying to simplify what’s usually a painful space - email setup, tracking, campaigns and make it feel way more straightforward.

Seeing real usage, feedback, and even small spikes already… hits different.

Still a lot more to build, but this is a big step for us.

Would really love to hear what you all think and what we should improve next.

@debojyoti452 built-in reputation monitoring is the sleeper feature here. 🛡️ Deliverability is getting harder every year, and most marketing tools just leave you in the dark until you're already blacklisted. How granular does the monitoring get do we get alerts for specific ISP blocks?

@abhiranjan_kumar2  Thanks for trying it out 🙌

Good to hear the setup felt easy - that was one of the main things we wanted to fix.

And yeah, the tracking part… we’ve felt that pain ourselves with other tools, so tried to make it a bit more clear and useful.

Would love to hear how it feels as you use it more.

@abhiranjan_kumar2 Really appreciate this, thanks for sharing 🙌

Hey @yotam_dahan, really appreciate the detailed feedback. This is exactly the kind of use case we're building for.

You're right on the money. We actually already capture provider-level bounce reasons on our end (Gmail, Outlook, etc.), but right now we surface generic bounce data to users for privacy reasons. Breaking it down by provider with specific bounce codes is something we can absolutely add. It's more of a product decision than an infrastructure gap.

I'll add this to our roadmap. Would be super helpful to stay in touch as we ship it. Would love to have you try it early.

@yotam_dahan +1 to this - this is exactly the kind of visibility we want to unlock.

A lot of teams end up guessing when something breaks, especially across providers. Making that clearer (and actionable) is something we’re actively thinking about.

Would love to keep you in the loop as we build this out.

@momen_elshamy Awesome,

Wish you a good luck 🙏🏼

@habiba_hossam Thank you! We’re glad to have you as part of the campaign,excited to have you with us on this journey 🚀🎉

@samirrashed Thank you so much for the kind words! Your support truly means a lot, appreciate it and wish you all the best as well! 👏🏻

@dina_mostafa Thank you so much, Dina! Really glad you like the style and found the categories helpful, means a lot coming from you 🤩

@yassmin_moghazy Thank you, Yassmin. Your contribution added great value to the project. Hope we get to team up again soon.

@aya_mustafa This is amazing..congratulations on bringing it to life! It clearly reflects a lot of passion and hard work. Wishing you great success with it, and looking forward to seeing how it grows 🤍

@ab80 Reddit is notorious for sarcasm how does your sentiment analysis handle the 'Reddit tone'? If you've solved for the sarcasm-to-sentiment ratio, you've built a miracle tool lol. I’m curious to see how the Leads module flags a post vs. just a random mention

@yotam_dahan Great questions, Yotam, thank you! 💫 I’ll try to be fully transparent here:

1. How fast is “real time”?
   It depends. We can’t honestly guarantee one fixed timeframe in every case. Sometimes a mention can appear in 2-3 minutes, and sometimes it may take a couple of hours. There are quite a few technical factors involved in how quickly content gets discovered, indexed, and processed.

2. Can you filter by subreddit and engagement level?
   Subreddit filtering - unfortunately, not at the moment.

Engagement level - partially, depending on what you mean. If you mean setting an exact engagement threshold in search (for example, “show only posts with 15+ comments”), then no. But if you mean sorting the mentions you’ve already found by a similar metric, then yes.

We don’t currently have a separate “engagement” metric, but we do have Reach, which is influenced by factors like the author’s karma and the number of comments on the thread.