Hello! I’m a long-time (very average) triathlete and a very high, very salty sweater. Like many, I’ve spent years tracking bottles and sodium, and using sensors and apps that tell me total sweat loss after a workout. The problem I kept running into was that none of this helped during the session, unless I relied on simple averages from previous data, which don’t adapt to intensity, heat, or fatigue. So I ended up building the tool I wanted to use myself.
The app gives a live estimate of cumulative fluid loss during the workout, shown directly on a Garmin Edge (and on the phone). It uses several live Garmin data like HR, power, duration, TE and temperature to estimate sweat loss in real time, updating every couple of minutes. It starts with a generic AI physiological model, and if you log real pre/post body-weight measurements, it trains a personalised model over time, so it learns how you actually sweat under different conditions.
It’s been working quite well for me and for the people helping with testing so far, and has proven useful for pacing fluids and sodium, especially on long rides and race simulations where conditions and intensity change.
If this sounds useful (even if you’re not necessarily a very heavy sweater but want to stop guessing), the project is called FluidLoss.info and it’s completely free for the foreseeable future. The Companion App is available on the App Store and Google Play (Android is still in beta, with access details on the website). The data field itself is downloadable from the Garmin IQ app. Unfortunately, other units like Wahoo make this kind of integration very difficult, so it’s not available there. There’s no need for accounts, logins, or personal data sharing beyond the metrics used for predictions.
Happy to answer questions or get feedback from this crowd. I hope this helps some of you!
Hello. Yes it has been compared to Flowbio sweat sensor (which has also been used extensively for the data collection). It has been done at various ride stages and for different total durations and the delta has usually been within 2 or 5%, depending on the session duration. Usually the longer the ride, the more accurate the result has been.
Most users have also simply weighted themselves before and after (tacking into account the fluid consumption) with similar results, but this obviously only applies to the total final fluid loss.
Hello. Yes, you’re correct — at the moment this only works for cycling.
This is due to how Garmin sport watches expose (or rather, don’t expose) real-time metrics compared to bike computers for custom apps.
Without an enterprise-level agreement with Garmin for Health, the current approach would be:
During cycling
• Use a custom data field on the watch to display the fluid-loss predictions
• Use the bike computer for cycling metrics
• Use the phone to handle communication between the devices and the AI prediction server
During running
• Use a custom data field on the watch to display the fluid-loss predictions (same)
• Use the watch to broadcast heart rate
• Get the remaining metrics directly from the phone, using its GPS and (less reliable) barometer for elevation
A dedicated running app is already in the pipeline. The AI model itself is trained for running and has been successfully tested. The next step is to combine everything into a seamless experience for the end user.
Apologies for the long explanation — I wanted to provide enough context in case you (or others) have suggestions.
Thank you for sharing this. This can be a component, but the big thing that is missing here and it is the biggest part of the equation, is the ability to uptake.
In Long Distance racing in extreme conditions where this would be a factor, the key component is how much is the individual able to consume in calories, fuel, and salt. Of course, what you lose can be a fact but is not very helpful if you don’t have the commensurate ability to uptake.
Your ability to uptake fluid and calories can be trained, and must be tested repeatedly under race intensity and conditions. It is hard to do and takes a lot of time, but without this the information in your app really would not be very useful.
Hi @david — Thank you for the comment! You’re absolutely right that in long-distance racing, uptake capacity is the primary constraint, not loss itself.
The intent of real-time fluid loss (from this app or any sensor) is to provide just another metric, not intake guidance. Similar to heart rate or power, it’s a metric that needs to be interpreted against what the athlete has already trained and proven they can absorb under race intensity and conditions.
As a high, extremely salty sweater myself, I’ve found that having this information reduces mid-ride uncertainty, but it doesn’t change the fact that, in my mid or full-distance events, complete replacement for me is not realistic and chasing it can create more problems than it solves.
That’s also why I’ve deliberately avoided features like manual sweat-rate input — I don’t want to encourage intake targets that exceed an athlete’s trained tolerance (there is already a lot of marketing around this topic at the moment).
So I fully agree with your point: loss data only has value when framed by individual uptake capacity and experience. Making that relationship explicit is important, and it’s something I now plan to highlight more clearly in the app.
Cool idea a live sweat loss estimate on the head unit could reduce a lot of guesswork on long rides when intensity and weather keep changing. If it can learn from pre and post weigh ins, how many sessions does it usually take before the estimate feels stable in hotter conditions?
Hello @davidrw The generic model already performs well across a wide range of conditions, so you don’t need lots of data to get accurate estimates. In practice, you’ll see things feel quite stable after fine-tuning the model with 5 to 10 good, varied sessions.
What matters more than volume is quality and variety. A mix of intensities, durations, terrain, weather, etc. gives the model better signal than many very similar rides. Using near-identical sessions to train the model can actually be less helpful than fewer, more diverse ones.