PH热榜 | 2026-04-06

@aaronoleary This is a really thoughtful execution, turning a complex mission into something lightweight and always visible . The timeline piece stands out. It might be even more useful if you add short context for each phase so non-space folks can follow along easily.

@aaronoleary Congrats, quick question: beyond Artemis II, any plans to expand to future Artemis missions or other NASA programs like Gateway?

@aaronoleary Congrats on the launch Moonshot! This is such a cool project turning the Artemis II lunar mission into a live countdown with real NASA data is genuinely brilliant and inspiring. The creativity behind it is really impressive.

As I went through the page, I missed seeing the final countdown interface in action right away. The concept is beautifully explained, but I didn’t get that instant “wow” feeling from actually experiencing it.

I’m genuinely curious how you thought about the user experience for something as special as a lunar mission countdown would love to hear your approach.

@moh_codokiai

There's no real clean API to pull this from.

I’m using NASA’s public Artemis mission pages and AROW tracking resources for the mission schedule and trajectory data, and then I do some processing to turn that into the countdowns, phases, event states, and visual mission path in the app. For some orbital context, I also derive values from structured trajectory/vector data rather than just showing raw page text.

It’s more “near-real-time from public mission data” than direct raw flight telemetry. It's got a high level of accuracy but it isn't designed to replace say NASA's own tracker. My thinking with this is: an app that I can check on the fly with a high-enough level of accuracy rather than browse to a new tab and risk context-switching.

@rustam_khasanov mission elapsed time is such a cool detail. I can quickly see how far the mission has progressed.

@craigcpaterson Should load! I'm in Ireland and it's working. Lemme check to see if I spot anything

@catt_marroll the coolest launch tag. Artisanal lmao with one pass for an issue!

@anusuya_bhuyan this is my favourite comment

@marcelo_farr Hey Marcelo!

Thanks for the kind words. Yeah, potentially. I'm half thinking of expanding into a mobile app, kind of like a flighty but for space missions. There's a ton of big things in space every year that aren't as publicised that I think people would be interested in.

@richard_andrews4 I was thinking this too! Gonna see if I can get it done!

@richard_andrews4 That would be epic , seeing the full trajectory in real time would totally bring the mission to life , can't wait to see it if it happens

@gabe It started as a simple tracker for the moon flyby phase but the nerd in me wouldn't sleep until I gathered every useful piece of data I could and presented it lol

@antoninkus Thanks! Hope you like it!

@umar_lateef ip whitelisting and ssh tunneling included? it’s clear you guys actually thought about the security side for agencies. most tools just focus on the 'cool' ai stuff and forget the boring (but important) infra.

@umar_lateef Congrats on the launch Rectify! The concept of an AI-powered visual debugging tool that turns user complaints and session replays into actual code fixes feels like a real game-changer for dev teams.

While browsing the homepage, I found myself wanting to see more of the actual AI in action, it explains the vision and benefits well, but I couldn’t easily get a sense of what the output or debugging experience actually looks like before signing up.

I’m really curious how you’re thinking about helping new users quickly experience the quality of the AI debugging early on, would love to hear your approach

@umar_lateef Some of my clients get bogged down with technical stuff. What's the learning curve like for Rectify?

@yanakazantseva1 Really appreciate you taking the time to write this, especially on your own launch day.

That says a lot about the kind of team you are. You nailed it, as agent systems scale, teams need visibility and structure or it all falls apart. That's exactly what we're building for. Love what you're doing with Ogoron too, automated test coverage that evolves with the product is something every team needs. Different layer, same mission. Good luck today, rooting for you

@abhra_das1 Great question! It's definitely not a gimmick. The 3D office gives you an instant visual overview of every agent's status so you can spot issues at a glance without digging through logs or lists. And you can actually chat with any agent directly from the 3D view, so if something looks off you can jump straight in and interact with it right there. Think of it as a live control room for your agents.

@krutytskyi We felt that pain too, way too many hours lost in terminal logs. Glad those days are behind you now. Thanks for the support today 🧡

@mirano_designs Thank you so much, this means a lot. Love hearing that you're already seeing results after connecting your OpenClaw. That's exactly what we built it for. If there's anything you'd want us to add or improve, don't hesitate to reach out. Your support hasn't gone unnoticed

@kavin_jeya Great questions. Yes, in the 3D office view you can visually see agent failures in real time. Agents that are stuck or failing are flagged so you can spot issues at a glance without digging through anything.

On the memory log side, you're right that debugging the "why" behind unexpected behavior is the hard part. We break it down so you can trace through the chain and see where things went wrong, whether it was a skill failure, a bad memory entry, or a model call that went sideways. You're not just looking at the outcome, you're seeing the steps that led to it. That clarity is what makes the difference between guessing and actually fixing the problem.

Appreciate the thoughtful questions, this is exactly the kind of feedback that helps us make the debugging experience even better

@buildwithomar Thank you! That's exactly the idea, agents shouldn't be a solo experience when you're working as a team. Would love to hear what you think once you dig in, your feedback means everything to us 🧡

@parth_solanki Really appreciate that, and you nailed it, RBAC plus client visibility plus Quanta's AI explanations is exactly the combo we built AgentPulse around. No formal case studies yet, we're still early. But honestly that's what makes right now the best time to get in. You'd be shaping the product alongside us, not just using it. We're actively onboarding teams and agencies running multi-client setups and building based on exactly that kind of real world feedback. If you're up for it, let's get you in and see how it fits your workflow. Shoot us a message, we move fast 🧡

@cuygun Great question. Right now we handle it through permission levels, so you can control exactly what each user can see, trigger, or configure. If a client needs more access, you just adjust their role. Plus everything is logged so you can see exactly who did what and when, no blame game, just clarity. And in the next iteration we're introducing rollback, so even if someone does make a change that breaks something, you can instantly revert to the previous working version. That safety net makes it a lot easier to give clients more control without the anxiety. And the best part is clients can interact with Quanta directly to understand what their agents are doing without needing to touch any configuration. Appreciate the kind words and love what you're building at TalkBuildr 🙏

@allen_pooley1 This genuinely made our day. Thank you for taking the time to write this.

You've been with us through the rough edges, the late night fixes, the back and forth on features that most people wouldn't even think to ask for. And honestly, users like you are the reason we build the way we do. Every bug report, every security request, every "have you thought about this" message pushed us to make Rectify better.

SSH Tunnel came from your feedback and for that we are ever grateful

Hearing that AgentPulse turned OpenClaw from a neat tool into something you're actually building with means more than any upvote ever could. That's exactly what we set out to do.

We're not done. Not even close. And your feedback will keep shaping what comes next 🧡

@malithmcrdev Really appreciate that, thank you so much 🙏 Means a lot to have your support. We're just getting started 🚀

@mykola_kondratiuk Exactly this. Solo is easy, everyone figures that out. The real challenge starts when you've got multiple clients, different team members, different permission levels and zero visibility into who's running what. That's exactly why we built role-based access and spend caps from day one. Glad it resonates 🙏

@sam_jesani thanks bro, the Earlybird.so launch helped a lot with growth and scale, we had some amazing feedback from the Bird Gang community and they are some of our most active users

@modii Ah , Finally an AI that doesn't just spit out random visuals😓 . Love how it's guided by what actually performs . Maybe adding some insights on which patterns work best by industry could make it even more actionable .

@modii Congrats on the launch Krev! The idea of turning a single product image into high-performing creatives like studio photos, video ads, and full campaigns using AI agents sounds incredibly useful for ecommerce brands.

What stood out to me is that the homepage focuses heavily on the vision and benefits, but it’s not immediately clear how the actual AI creatives look or feel in practice before signing up.

I’m really curious how you’re thinking about letting new users quickly preview or experience the quality of the output early on. Would love to hear your approach.

@modii Hi Modi！Great launching！This looks genuinely useful, especially for teams like us that need to create a lot of product creatives fast. One thing I’m curious about from a user experience side: after Krev generates the assets, how flexible is the editing step if you only want to tweak a few details instead of regenerating everything?

@appelton Thanks for the feedback and it's a really good point. I'll surface the /ads endpoint into the API as well.

@abhra_das1 Thank you, indeed it is a bit nerve wrecking.

It’s a mix of both. We pull live data from a curated set of brands on Meta to understand what’s actually running right now, and then layer that with structured creative patterns we’ve built from high-performing ads.

So instead of generating from scratch, KREV starts from signals and proven frameworks which is why the output tends to feel much closer to actual ads.

@ben_gend Great point, that’s exactly the gap we’re focused on.

And yes, this works for app products too.

The way I'd approach this is the “product” becomes your UI. You can feed in key screens or flows, and KREV treats those as the core asset.

From there, you can generate ad creatives using software/tech patterns or even UGC-style formats built around your UI.

Brand DNA still applies as well, so everything stays consistent with your product’s look and feel.

Would actually love to see this used for a launch like yours and I'd love to get feedback!

@mykola_kondratiuk Definitely agree. I’d add one more layer to that as well: performance-based "on-brand" creatives.

@mykola_kondratiuk But how to prove the good performance? Connecting with the social media ad system?

@aadhitya_muralidharan Right now it’s a mix. We pull real-world signals from a curated set of brands and combine that with structured creative patterns.

The goal is to move beyond just pattern-based generation into something that continuously learns from what’s actually converting.

@yanakazantseva1 Appreciate that, you captured it really well. That shift from “looks good” to “actually converts” is what we’re betting on.

Also love what you’re building with Ogoron. Feels like a very similar mindset applied to a different layer of the stack. Will check it out and good luck with your launch as well 🙌

@adam_perlis I'm sorry to say, your app doesn't support Bangla language at all. Bengal is my mother tongue and it has almost 300,000,000 speakers or one of the top 5-6 languages on earth. I have tried the free version and then I could not type a single sentence.

 What I did next? I changed the language and worked with English language. Well, I have to say that your level of accuracy is great. I don't have any complaint about it. As you can see, I have typed by using your app Waki and presenting here. But the main problem is that in the free version, it takes 30 to 40 seconds to transcribe only 100 words.

 This is frustrating and there are plenty other options available. So I suggest that you take care of this matter if you really want to get a decent number of users.

My OS: Windows 11 and 16GB RAM

@adam_perlis Then I tried the paid or fast version and at first I typed some words in English language. The speed is fair enough, I have no complaint about it and I think that the paid version works quite well as far as speed is concerned. However, in your description you have pointed out that you wanted to offer a free alternative but I think that you need some catching up to do.

And in the fast or paid version, the accuracy level is quite good, great.

Then I tried with my mother tongue or Bengali language. The level of accuracy is not good. It made too many errors. The speed for the Bengali language is fine, but as I stated earlier, it is unworkable because of the errors.

Overall as a new product, it is good and I wish you all the success. Thanks a lot for coming up with a good app for speech-to-text or speech-to-recognition. I am hopeful that in coming months we will see a lot of developments from you.

@adam_perlis What's the biggest frustration you had with Wispr Flow's paid basics that inspired this free alternative, and how did fixing it change your own workflow?

@prateek_kumar28 I have found that if you try it a few times with the same word and just keep correcting it or adding the correction manually in the Walkie setting its usually nails it.

@pal_gai Yes any language support here: https://whisper-api.com/docs/languages/

@rustam_khasanov while I am not able to share our trade secrets with a competitor haha I will say that we did lots of research to figure this out.

@cyberseeds I have not tried anything that long but if you want to test is and send me the results I would love that! TBH its likely a better idea to use a different tool for that purpose that would record first and transcribe later. Seems like an edge case but if there are more people who want this we could probably figure it out.

@conduit_design what do you mean by clean?

@fraser_svg both modes have some level of formatting. So on the local side you get basic formality stuff. But in the fast mode you get a bit more thoughtfulness. For example, lets say you said "Let's meet for dinner at 7pm or actually 8pm." it would auto correct to "Let's meet for dinner at 8pm." There are many scenarios where its just more intelligent about how it formats. Its also context aware so it knows the app your in and adjusts the context, for example in an email or a Slack.

@gautam_borad1 Excited to see this live .

But I am curious bout if the AI agent can identify entirely new audience segments or is it focused solely on optimizing the ones already running ?

@gautam_borad1 Congrats, quick question: for someone juggling Meta/Google/Shopify now, what's the fastest semantic layer win to test before full setup?

Thank you @alara_akcasiz !!

Hi @ben_gend well it depends on which part you're asking about.

AI Creative scoring works from Day 1. Upload your creatives before you spend a dollar and Predflow will tell you what's wrong with the hook, the CTA, the awareness stage fit, etc. That's actually where most launch budgets get burned, and they are just fixable creative problems nobody caught.

For budget allocation and other recommendations, you need a few weeks of data.

The other thing that helps early-stage brands specifically: because your UTM data is clean from the start, you avoid the mess that most brands spend months trying to untangle later. And believe me its quite a task! Setting up the semantic layer before you launch means your Month 1 data is actually usable. Most brands come to us after the data is already broken.

@mykola_kondratiuk  great question! This is a hard problem to solve. First we surface every unique value alongside its count, then we let the brand define which mapping to take preference.
The harder edge case is when two teams have been using the same tag to mean different things. This one we genuinely can not resolve without a conversation with the brand.
For such problems we give the humans how hold the knowledge a clean interface to encode it once, so the Semantic Layer is consistent and clean.

Hi @ermakovich_sergey ! Currently our agents optimize whats already running (existing campaigns). Budget allocation, creative fatigue, channel-level ROAS, root cause when something drops.
Audience segment suggestions are on the roadmap but we haven't shipped that yet.

What we do have is cohort-level analysis: new vs repeat customers by source, channel, product type, etc.

This ends up surfacing a lot of the same insights indirectly. "Your Meta campaigns are acquiring first-time buyers at 3x the CAC of Google" is a budget insight but it's also telling you something about who each channel is reaching.

@ece_kayan  @chrisbattarbee 
I’ve been burned by 'AI SRE' promises before, but your approach to the data problem (eBPF) makes this actually feel technically grounded.. Really great to see

@ece_kayan  @chrisbattarbee eBPF is the part that made me stop here. Most tools in this space sound great until the data gets patchy. Starting with your own telemetry makes the whole thing feel a lot more believable.

How often are teams merging the PR as is?

@ece_kayan  @chrisbattarbee Congrats on the launch Metoro! Really impressed by the ambition here, an AI SRE that can spot, diagnose, and even fix Kubernetes incidents on its own feels like a big leap for platform and SRE teams.

I spent some time on the homepage and honestly found myself wanting to see the AI in action a bit more. The vision is clearly laid out, but I didn’t get a strong sense of what the actual fixes look like or how smooth the whole process feels before signing up.

I’m genuinely curious how are you planning to let new users experience the real power and speed of the AI early on? Would love to hear your thoughts.

@anil_yucel1 

Hey Anil :)

So we offer three distinct hosting options:

1. Metoro Cloud - Fully managed by Metoro, Metoro manages the infrastructure in our environment. Telemtry data is stored in our cloud environment

2. BYOC (Bring Your Own Cloud) - Managed by Metoro, hosted in your cloud - in your case in your Azure account. Telemetry data is stored in your cloud environment in buckets that you own but Metoro operates (Azure Blob Storage in your case)

3. On Prem - Fully managed by you, we just provide support. Telemetry data is stored wherever you choose to host Metoro, we support cloud based storage options like s3 and Azure blob storage or disk based solutions too (SSDs are recommended)

Yep we fully support AKS, no limitations!

@alexander_zakon Yes!

So each k8s cronjob gets mapped to a service internally in Metoro. Then each service is assigned a codepath which is a combination of repository and source path. It looks something like:

sourceRepo: https://github.com/org/repo
sourcePath: /src/cmd/... 

Metoro discovers those automatically by itself by comparing emitted logs, profiling information etc but you can also set it manually by setting an annotation on the pod or the CronJob itself https://metoro.io/docs/integrations/github#option-1-using-kubernetes-annotations-recommended

@joe_hewett1 Thanks Joe!

Yep there's a couple levels

In cluster components

All of our monitoring is done out of process via eBPF which lives effectively isolated in the linux kernel. So lets say we have a bug, it isn't possible for us to affect your services, worst case we wouldn't be collecting telemetry.

Data Security For The Agent

All agents run without internet access and have tight RBACs so they can only see specific subsets of data. This way it's not possible for the agent to accidentally exfiltrate data

@vouchy Yeah there were a bunch of times to be honest. The shape is a bit different each time but the cause is the same.

Super common example that it ran into was not knowing the "lore" behind a metric. One concrete example is this: The agent would work its way down through an investigation and would be arriving at the conclusion that there was a resource bottleneck for particular service. It would see that there is a metric: "cpu_utilization_serviceX" so it would query that. However that metric would have a "mode" attribute that has a bunch of different values.

Looked like this:

So in order to get actual utilization it needed to do a sum across all modes where the mode is not equal to idle.

The agent just wouldn't know this (as you likely wouldn't as an engineer without context) so it wouldn't be able to nail down the root cause.

This is the sort of thing that consistent telemetry solves.

These instances add up and it's a "death by 1000 papercuts" situation.

@alibi_yeslambek For sure.

So by default the AI SRE sets up anomaly monitors on things we classify as golden metrics (think RED metrics and some infrastructure level signals). The anomaly monitors there run at different timescales, we have O(minutes), O(days) and O(weeks) right now. If anything breaches those thresholds then the agent will investigate, determine whether or not its noise and ping you if it actually is a problem.

You can also specify metrics that you want to have monitored manually if that's more your style too

@chrisbattarbee  @josh_bennett1 

Great question! If the issue spans multiple services, multiple investigation agents are spawned across the affected paths instead of assuming one service is the problem.

They follow the dependency graph from eBPF-generated traces and investigate each branch using traces, logs, metrics, k8s state, deploy/config diffs, and memory (what it already knows about that services behaviour). That lets us separate the first real failure from the downstream.

If there is a clear initiating fault, we identify it. If there isn’t, we surface the causal chain and candidate failure points with evidence instead of pretending there is one neat root cause.

@chrisbattarbee  @moh_codokiai Thanks Muhammad!

Really good question and I agree, code fixes are one of the hardest parts. To be clear, we don’t do blind auto-remediation.
Metoro is human-in-the-loop: it investigates the issue, identifies the likely initiating failure, and then suggests a code fix (which you can open a PR) for an engineer to review or for a coding agent to work on it further. We do this very intentionally to make sure that the fixes go through the same safety mechanisms that a normal release would go through.

To reduce the risk, the suggestion is grounded in eBPF telemetry, topology, infra context, recent deploys/config changes, and the actual code path, so we are not just reacting to one noisy symptom. Its crossed checked against telemetry, infra and code.
Then once the change is deployed, we verify the rollout against production telemetry to see whether it actually resolved the issue or caused regressions (the ai deployment verification feature).

It’s not a fully autonomous remediation system yet, but it is designed to get teams 80%+ of the way to resolution.

@ece_kayan  @shrir Amazing, thanks Shrirang!

@saturnin_pugnet So if those apps are running in Kubernetes then we work on those too. We hook into the source code via a github integration so we can debug application level issues too.

The classic use case is that a bad deploy ships, we can see exactly which parts of the code change and deeply investigate the endpoints that have been changed to understand if there's an actual regression based on our telemetry

@vikramp7470 Thanks Vikram!

So we've had to address this problem a lot right now with quite a few of our customers.

Essentially we apply anomaly detection to remove a lot of the baseline of 20% of the requests to this service generally result in a 5XX response.

Then after that, the agent will run an investigation to see why a spike happened. When we find the root cause we create an 'issue'. Now next time we run an investigation we check to see if the root cause of that issue was a recurrence of any other issue. If it is then we just add it as a recurrence of that issue. We dont ping teams for issues that recur frequently so we reduce the noise that way.

This keeps the list of actual issues small and concise so you can see what issues you need to address. You can quickly see "this issue recurred 20 times in the last 3 days" so we should probably address it

@yanakazantseva1 Thanks Yana, best of luck with your launch too! Ogoron seems pretty cool :)

@paul_vidal Thanks Paul!

For sure, onboarding is however you like! Either just install it yourself (after logging in you'll be given the single helm command) or if you book a meeting here https://cal.com/team/metoro/engineer I'll be sure to pick it up and run you through it :)

@abin_paul1 Hey Abin, good question. So for each protocol we only pull out known non-sensitive parts of the request.

As an example, think http.

We dont export all headers for example or the body, but we do export URL parameters, path, url etc

Effective each protocol has a default allow list which you can augment yourself.

@mykola_kondratiuk For sure we definitely agree with you. That's one of the main reasons behind using PRs in the first place, before the PR is merged you should definitely be reviewing or using tooling to help verify the PR (like all the other PRs!)

@mazirar I’m curious how you handle spam emails.  

The biggest headache for me with my helpdesk is all the marketing emails I get every day. I never signed up for them, and no matter what I do, they keep coming. Deleting them takes up so much of my time.

@mazirar Congrats on the launch! As a solo founder juggling multiple inboxes, do you see easy ways to tag/route tickets from different domains without workflows? Super curious on that front.

@richard_andrews4 Woah, an integration with Notion could be a game changer.

@richard_andrews4 this. Or linear!

@becky_gaskell Great question 👋

The goal with Mailero isn’t to remove structure — it’s to remove unnecessary complexity.

Instead of workflows, we keep things simple but effective:

• Each email becomes a ticket with a clear status (open, closed, etc.)
• You can set priorities and categories to organize what matters
• Conversations are threaded, so you always have full context
• There’s a clear “awaiting reply” vs “needs action” view to track ongoing issues

So you still get visibility and control, just without automation rules or workflow builders.

Curious — what kind of tracking or prioritization do you rely on today?

@saaswarrior It works for me.

@elena_nimchenko Kudos on the launch. How does Ogoron handle flaky tests or UI changes that break coverage over time?

@nick_mikhailovsky1 BYOK makes sense for power users, but I’d optimize for a frictionless first experience with a managed key and move people to BYOK after they see value.

@mykola_kondratiuk That is a very fair question. Hard exceptions are a real limit for QA automation, especially as scope expands.

Our view is fairly pragmatic: the boundary is reached when the correct behavior cannot be reliably reconstructed from the available artifacts – code, tests, specs, documentation, and the behavior of the product itself.

So our recovery model is to recover automatically where the system can establish a high-confidence truth, and surface ambiguity when it cannot. In practice, that means Ogoron can adapt a lot of standard cases on its own, but in genuinely disputed or under-specified situations it asks the user to resolve them explicitly rather than pretending certainty.

A big part of the product is expanding that high-confidence zone over time – from general web patterns to increasingly domain-specific behaviors

@konstantinkz Thanks – in the standard managed setup, some data does pass through our infrastructure, and requests currently also go to OpenAI as the external LLM provider.

So if your requirement is that absolutely no data leaves your network, we should be transparent: we do not fully support that today. We can discuss deployment on your own infrastructure, but external LLM calls still remain part of the current architecture

@fraser_svg Thank you for the great question!

When some tests fail you run

ogoron heal

It puts every failed test into one of three classes:

• code bug

• test bug

• unsure

Test bugs are then fixed by Ogoron

The bugs in "unsure" state need human review. Our experience with pilot customers show 10% to 50% tests fall into this category, depending on a project. Our experience also show that about 15% of the failures are incorrectly classified.

Once a human have put the failed tests into test bug category, they can be fixed by Ogoron.

@umar_lateef Thank you so much – that really means a lot to our team.

We really appreciate your kind words. Wishing AgentPulse a great launch as well

@umar_lateef Thank you so much, Umar — this truly means a lot to me 💛

I really believe that supporting each other, especially on important days like launches, is what makes this community so special.

@lida_vengerskaya Great question! The pattern we observed the most is that with Ogoron, manual testers get into automated testing, but further QA hiring at our customers stales.

@artem_galeev Thank you for the great question! You correctly noted that Ogoron generates tests but don't run the tests by itself. And in a strong ML sense it does not learn from the bugs. But all the tests and their results eventually get into the context Ogoron uses, so in a sense it does learn

@alibekovand Good question. A long commit history by itself is usually not a serious issue.

Most codebases can be read progressively, layer by layer, so what matters more than the raw number of commits is the current architecture of the project and how much useful signal exists in the code, tests, and docs.

We have already tested Ogoron on many large repositories, including products that have been developed for more than 10 years. So a repo with 10,000+ commits is well within the kind of scale we expect to handle.

@alexey_kochetkov Both the hybrid and pure on-prem are in our backlog

@comrade_komissar Yes, Ogoron is a SaaS (SaaS inn't dead:) ) so the code sanippets are transferred to our LLM providers (mostly OpenAI). We are happy to discuss on-premise deployment with qualified customers

@francis_dalton Very fair point – edge cases and unexpected flows are exactly where automated QA usually starts to get real.

Our view is that the goal is not to pretend everything is expected. It is to recognize when the system is operating inside a high-confidence pattern, and when it is not. When Ogoron can reliably interpret the situation, it handles it automatically; when it cannot, it surfaces the ambiguity instead of forcing a false answer.

A big part of the product is continuously expanding that high-confidence zone. In practice, many "unexpected" cases are not unique at all – they are recurring patterns that different teams have already run into in one form or another. A lot of the work is turning more and more of that real-world experience into something the agent can recognize and handle safely

@daniil_kadeev Thanks – very important question.

A big part of the value here is that Ogoron generates tests which can then be used independently of Ogoron itself. We also do not restrict running those tests through Ogoron, and test execution remains free, so this part of the workflow is not something we want teams to feel locked into or blocked on.

For early users, we are also quite hands-on with integration support. If something blocks setup or rollout, we usually help directly and quickly rather than leaving the team to handle it alone

@sevryukov_vs Good question. The analysis can go fairly deep when the business logic is actually expressed in the artifacts available to the system — code, product behavior, specs, and provided documentation.

If the rules are complex but still fairly standard for the domain, modern models are often much better at reconstructing them than people expect. We were honestly surprised ourselves by how much sensible structure they can extract directly from code.

That said, we try to stay realistic: if critical business logic is not recoverable from the available sources, Ogoron should not pretend to understand it perfectly. In those cases, trustworthy grounding and user clarification still matter

@lordice222_james James, please drop me a email at nickm@ogoron.com. We had Cypress in our product map, but not immediately. If you are ready to start immediately using ogoron if we suppurt Cypress, we can move Cypress up in the backlog

@anna_drobysheva Good follow-up question.

No special firewall rules are required beyond normal outbound access for the CI job. The main thing is that the runner can reach our services and the OpenAI API.

On the permissions side, it is also fairly standard: repository access, and if you want automated change flows, permission to commit or create changes back into the repo.

We also support file-level allowlisting, so if there are parts of the repository or configuration you want to keep outside the agent’s scope, that can be restricted

Thank you for the great question!

@iosfixed A lot of business cases can actually be derived from the website copy and public documentation. All the business cases that Ogoron have derived are available for the human review in the for humans tree. You can also put the documentation into the repo and Ogoron will use it.

We do have the integrations with Jira, Confluence and Notion in the product backlog. Drop me an email and I will let you know when the integrations arer available

Hi Karina! Yes – for GitHub, we already support this via a GitHub Action, including workflows that can open pull requests with generated changes.

For other Git-based systems, the integration is not yet fully packaged, but we do provide a CLI, so setting up an automated PR flow is usually quite simple – basically a couple of extra shell steps beyond calling Ogoron itself.

The main thing that is still GitHub-first for now is self-serve billing. For other systems, we can support early access directly – feel free to email me at vmynka@ogoron.com

@astepanov Thank you for your question – yes, we already have example snippets for several common GitLab CI setups in our docs at docs.ogoron.ai.

If your pipeline is a bit more specific, we can usually help adapt a template for it fairly quickly.

The main caveat today is that GitLab is not yet fully supported through the self-serve dashboard: repository connection there is still GitHub-first. But if you want to test Ogoron with GitLab, feel free to reach out to me or Nick for early access

@adamspong Thanks for the question. To clarify, Ogoron is not about strict TDD in the classic sense. It is an automated QA system that generates, maintains, and runs tests as the product evolves.

In most workflows, that fits before code review: when a branch is ready, tests are refreshed, smoke checks run on pushes, and the broader suite can run before review or merge

@teimy Please drop me a message at nickm@ogoron.com and we will figure out something

@aleh_suprunovich Thanks for the question! Yes – containerized applications are very much in scope for us, and Docker is currently the primary path we support.

Deeper support for orchestration layers like Kubernetes and AWS ECS is still on our roadmap, but in practice containerized environments are usually a natural fit for Ogoron rather than a problem. The container boundary gives us a fairly clean and unified system-under-test, which is often helpful for automation

@toki_tango Great question!

In practice, Ogoron is a CLI-first tool, so authentication is usually handled by the environment it runs in. For GitHub, we already support private repositories through our main integration and billing flow.

For other Git systems, the setup is still more manual today, but it is straightforward to support via the CLI as well. If that is relevant for your setup, feel free to reach out to me at vmynka@ogoron.com for early access.

As for private runners, there are no special restrictions on our side. The main requirement is that the runner must have network access to our services and to the external LLM provider endpoints we use, which currently means OpenAI

@albertjo  The form correction through the camera is really well thought out. Most PT apps just show you a video and hope you're doing it right. Using the phone's camera to actually check your movement is where native iOS hardware access pays off.

@busmark_w_nika Definitely!

Hey @abhra_das1! Yes, based on your feedback and progress, Adapted tailors and updates your sessions accordingly (scaling up/down the difficulty/intensity). The programs are not static.

@nayan_surya98 Great question! The primary factors are the specific joints/regions you want to focus on, your sport, your training schedule, and injury history (if applicable). Age and gender are collected but play a secondary role - the program is more built around your sport context and goals.

@codenameakshay For non-tech users dipping into workflows like daily research or team updates, how does the persistent memory hold up over a week of real Telegram chats, and what's top on the roadmap to make it even smoother?

@codenameakshay love the focus on persistent memory. most telegram bots have goldfish memory and you have to re-explain everything daily. if this keeps the context intact without fly.io headaches, i’m in.

@deangelo_hinkle yeah it is awesome

@dubeypt Ahan , this feels more real than most finance tools . People don't just need info , they need clarity, and this sort of comparison really helps. Maybe adding small progress tracking could make it even more engaging.

@dubeypt This is going to make my monthly planning a lot smoother—being able to clearly see what an extra $50 does to a payment is super helpful.

@abhra_das1 

Great question, Abhra

Our hybrid strategy combines both interest rate (like Avalanche) and balance size (like Snowball) to optimise payoff.

1. It prioritises higher-interest debts to reduce overall interest

2. While also factoring in smaller balances to create quick wins and keep momentum

So it’s essentially a balance between cost efficiency and motivation.

You can see how the payoff order updates in real time when you enter your debts — would love to hear your thoughts after trying it!

@mathew_chang 

That’s awesome to hear, Mathew.

Glad the extra payment impact feature is helpful. Small changes can make a big difference over time.

Appreciate you trying it out!

@shania_jennings

Thanks for pointing that out, Shania

Really appreciate the feedback, I’ll look into improving the chart scaling for smaller screens.

Let me know if you notice anything else! 

@judith_wang

Thanks, Judith!

Really glad you found the hybrid strategy interesting — that’s exactly what I wanted to explore beyond the usual fixed approaches.

Would love to hear your thoughts if you try it out! 

@keith_hiyamojo 

Great point, Keith 🙌

Right now, the calculator assumes fixed interest rates for simplicity, but factoring in variable rates is something I’m definitely considering for future updates.

Appreciate you bringing that up!

@hirokiyn Congrats. How would you recommend structuring a shared pack for a team's 'personal branding playbook' to make it plug-and-play for Claude or ChatGPT agents?

@hirokiyn Congrats on the launch, Hiroki! The idea of 'portable memory' is a massive unlock for team-based AI workflows. We often see valuable context getting 'trapped' in individual chat silos, so making it reusable across mcp and cli is a brilliant move.

As someone hunting for AI agents that actually work in production, I'm curious about the 'context drift' problem: When a Context Pack is fetched across different models (say, from Claude 3.5 to a local Llama 3 setup), how do you ensure the semantic integrity remains consistent? Different models interpret 'know-how' differently—do you have a standard schama to ensure the agent doesn't misinterpret the 'decisions and reasoning' within the pack ?

Looking forward to exploring the community packs～

@abhra_das1 Not just prompts.

A Context Pack can carry the surrounding context too, like decisions, rationale, project background, conventions, and other working knowledge behind the workflow.

The goal is to reuse understanding, not only reuse prompt text.

@mykola_kondratiuk Good question!

We keep track of how often a pack is used and favorited, so higher-value context naturally stands out over time while lower-value entries get pruned. A good pattern on top of that is to have agents periodically run an organize workflow to clean up, merge, and reconcile overlapping context.

@abhra_das1 Hey Abhra! So you do need the SDK, but honestly it's two lines. Just wrap your Anthropic client with wrapAnthropic and you're good to go. No framework, no setup headache.

The replay thing works because Glassbrain snapshots your exact call (prompt, params, model version, all of it) so when something breaks you just go into the dashboard, tweak the input, and fire a real call right there. Never touch your codebase. For someone who dreads the debug process this is kind of the whole point. Give the free tier a shot, would love to hear how it goes with your setup!

@sai_ram_muthineni The replay part is the hook for me. Finding a bad run is one thing. Getting back to it cleanly is usually where time disappears. Does replay end up replacing manual log digging for most teams?

@sai_ram_muthineni Congrats on the launch, Sai!

Debugging multi-step agent pipelines through json walls is a nightmare, so the 'visual trace tree' approach is a massive UX upgrade for developers. The ability to replay from a specific node without redeploying is the real hook here.

As someone deep-diving into AI orchestration, I'm curious about how you handle 'Stateful replay': If a node three steps deep relie on a specific local state or a previous tool output that isn' t part of the LLM prompt, can Glassbrain still reconstruct that environment for a deterministic replay. Or is the replay primarily focused on the stateless LLM call parameters?

Two lines of code for integration is the right move. Can't wait to try this on our next agent trace.

@avi_pilcer1 Yeah Avi, that's exactly the direction. The replay infrastructure already stores everything we need - exact prompts, params, model versions, original outputs - so wiring up scheduled regression runs is more of a scheduling problem than a hard one. The plan is: pick a set of "golden" traces per project (your critical paths), run them on a cadence, diff against the stored baseline, and alert when outputs drift beyond a threshold.

The interesting part is what counts as "drift worth alerting on." Exact string match is too noisy because LLMs vary even at temperature 0. Semantic similarity is better but expensive at scale. Probably something like: structural diff (did the JSON shape change, did a citation disappear, did the tool call sequence change) for fast checks, with semantic embedding diff as a fallback for free-form text. Still figuring out the right thresholds.

If you've thought about regression testing for AI before I'd love to compare notes - this is the kind of feedback that actually shapes the feature.

@mykola_kondratiuk Hey Mykola, yeah this comes up constantly with agents. The snapshot side of it stores everything deterministically (full prompt, params, model version, tool outputs) so you always have the exact state of a run to go back to.

Worth being upfront though: replay does make real LLM calls via your API key, it's not a fully offline re-run. What it removes is the "reproduce this in your codebase and redeploy" part, which is usually where the time actually goes.

@thenomadcode Hey Christophe, yeah it handles multi-step chains. The SDK wraps your Anthropic/OpenAI client, so every call from every step gets captured automatically. Whether it's a single completion or a 10-step agent pipeline with retrieval, tool calls, and nested LLM calls, each node shows up in the tree with its own inputs, outputs, latency, and tokens.

You get the full execution graph, so when something breaks three steps deep you can see exactly which model call produced the bad output and replay from that specific node. It also picks up LangChain and LlamaIndex pipelines since those wrap the same underlying clients.

@natanel_alaev Thanks Natanel, appreciate it. Great question - just the full pipeline run counts as a trace, not individual nodes. So one end to end call to your AI app, whether it's a single LLM completion or a 15 node agent pipeline with retrieval and tool calls, is one trace against your 1K free tier.

Clicking around inside a trace to inspect nodes is free, and replays don't count against the trace quota either (they hit your own API key on the LLM side). The 1K is really about how many real runs your app does per month, which keeps it predictable. Most devs on the free tier are building something new and using it for a few weeks of dev/testing before deciding to upgrade.

@jabohabo that research notebook feature sounds like a lifesaver for anyone doing heavy documentation. capturing the url and the app automatically without switching tabs is a massive win. definitely checking out the trial today. Great

@jabohabo Really like the 'stay in flow 'angle her , That's a real pain point most tools ignore . The research notebook feature sounds especially practical .

How does HyperCap compare in speed and flexibility to tools like Raycast or Alfred when workflows get more complex?

@matheusdsantosr_dev Hey Matheus, thank you so much for the kind words and for actually taking Lito for a spin!

You're absolutely right about the protocol prefix (http/https). That's a great catch! We currently expect the full URL to ensure the most accurate redirection, but making it smarter to auto-fill the protocol is definitely on our immediate roadmap to make the experience seamless.

Glad you liked the analytics interface - we spent a lot of time making 'unique views' as clear as possible. Looking forward to more of your feedback as you test it further! What kind of projects are you planning to track with Lito?

@misbah_abdel Great question! Because Lito uses a Campaign structure (where ONE target link has MULTIPLE short links for different channels), currently you insert the exact URL you want as the target for the whole campaign.

But you are absolutely right about the need for native handling! My plan for the next update is to allow attaching UTM parameters directly to the individual short links within a campaign. This way, your QR code remains perfectly short and scannable, but Lito will automatically append the correct UTMs (like ?utm_source=qr_menu) during the redirect.

For now, it redirects exactly to the target URL you provide. Thanks for the feedback, this validates my roadmap perfectly!

@aya_vlasoff 
Thank you Aya!
Mobile format is fully in scope - Stories, Reels, the works.

Mobile actually changes the attention math a lot. On desktop you have a few seconds. On mobile you have one, maybe two, before the thumb moves. Our models are calibrated for that window specifically, so you're not getting desktop predictions dressed up for mobile.

For a zero-budget launch, running validation before spend makes a lot more sense than A/B testing after. If you want, share a format you're working with and I'll be happy to show you what the attention map looks like on something real.

@guillim 

Nice job

@devrabb that’s the way to go. My biggest advice would be to use Claude desktop to do all the work for you !!! Or use OpenClaw

@misbah_abdel it’s 100% compatible with mobile apps. You should definitely use it when releasing an IOS app. I did it myself for a macOS app a few weeks ago. And I had feedbacks from fellow makers that did it for mobile apps , exactly like you

@hubert_de_renoterre yes using Claude desktop, or perplexity computer use, or any other solution that let you control your laptop like OpenClaw you can, ask your machine to list your product on all the websites listed. Pretty easy TBH, and much cheaper the the traditional paid solutions like ListingBott