Having fun with AI: Can it help us roast better? 🤖

Roasting on the Bullet
1

Hi everyone!

In this age of AI, I’ve been playing around with a simple question: “How can we use these new tools to make our roasting sessions even more engaging?”

I find Scott Rao’s focus on the RoR curve very helpful for managing that critical window around the First Crack (FC). To help me stay one step ahead and avoid those frustrating “crashes,” I decided to try a unique experiment suggested by my AI Copilot.

The Experiment:
I’m testing a physics concept called Critical Slowing Down (CSD). It’s a way to detect “invisible wobbles” in data that happen just before a major change (like the First Crack).

The Implementation:
I built a retro-style “Roasting Copilot” that monitors these signals. It gives me a systematic “heads-up” alert about 30–90 seconds before the beans actually start popping, allowing me to adjust power and fan settings proactively to keep the RoR curve smooth.

I’ve shared a short demo video and my initial findings here:
:point_right: Can First Crack Be Predicted?

Roasting is so much more fun when we can “see” the invisible physics!

Happy roasting!

4 Likes
2

Wow! That is bloody interesting!!!

I do not pretend that I understand what exactly you have done here, but I appreciate the thought process you have undertaken.

Would love to try this myself, but too computer illiterate to even dare.

Well done arigato!!!

1 Like
3

Thats very cool and an excellent idea.

Im still quite new to coffee roasting and will occasionally ask gemini to analyze my roasts and make suggestions on how to better bring out target flavors.

Overall, Its been a mixed success.

1 Like
4

I have actually been stewing on a similar idea of an agent integrated in RT, so this is cool to see something in action.

Also, I like the vibe of your blog there. Thanks for sharing.

2 Likes
5

Sorry arigato, I have so many more questions…

1.) In the links you posted, you show an accuracy analysis with 31 profiles. Would you not be able to do extensive back-testing on all sorts of roast runs you (others) have done previously?

2.) I find the definition of FC to be a relatively fluid/flawed concept, so I wonder how much the accuracy of your “early warning from CSD” is affected by the inherent inaccuracy of determining the exact time at which FC occurs?

3.) What sort of algorithm do you use to detect the actual CSD - i.e. autocorrelation and variance in the ROR data? I can understand if you want to keep this private, in case you are looking for a commercial application of what you have discovered, but interested to better understand, in case you are just doing this for fun.

4.) Having run 31 samples, do you have a sense of how much further your method could be optimised in order to improve prediction accuracy? What do you believe are the limiting factors for improving this method - probe measurement accuracy or sampling frequency, or any other parameters?

5.) I imagine that this would be most useful to apply on a new coffee bean that you have never roasted before and whose FC characteristics are completely unknown. I wonder how a super experienced roaster would approach such a roast (i.e. not knowing when to expect FC, but aiming to dial down heating or increasing fan speed in anticipation)? This method could really save time, money, and precious beans!

6.) I always admire creativity and innovation. If you are willing to share, I’d be interested to know to what extent you stumbled across this idea all by yourself or if it is the logical progression of ideas you have seen being developed by others?

I have now ordered my Bullet, but it will probably be June before I get to do any roasting on it, so I am writing from a certain position of ignorance.

PS: There is a typo in mcaillio’s post above. I am sure he meant to write “…I have actually been brewing on a similar idea…”

6

@1stinline4model3.lha Thanks for the great questions. I’m happy to share the details since this is just a personal project for my micro-roastery.

1.) & 4.) Back-testing & The Ethiopian Bias You’re right—my current analysis is heavily biased toward Ethiopian Naturals (mostly because I love them too much!).

There are two reasons I haven’t done extensive back-testing on other datasets yet. First, exporting and cleaning hundreds of historical logs from RoasTime into a format my script can digest is a bit of a manual nightmare! Second, the current threshold (AR(1) >= 0.35) is definitely overfitted to the explosive moisture-loss behavior of high-density Ethiopians.

The logical next step for optimization would be Dynamic Thresholding: analyzing the early drying phase to classify bean density and auto-adjusting the CSD threshold.

2.) FC Definition & Thermal Proxy To eliminate human reaction-time noise and keep the data consistent, I marked “FC” in these 31 profiles using a strict thermal proxy: when the physical BT probe hits ~190°C.

This “190°C rule” worked mainly because I was roasting almost the same types of Ethiopian beans with consistent thermal properties. Interestingly, the CSD signal (AR(1) spike) appears roughly a minute and a half before the probe hits that mark. It seems the algorithm is detecting the internal thermodynamic phase transition well before the sensors capture the macroscopic result.

3.) The Algorithm It runs a Kalman filter on live BT data to clean noise, then monitors the rolling variance and lag-1 autocorrelation (AR(1)) of the “innovations.” Full disclosure: I relied on Claude Code for the Python implementation. I understand the surface-level physics of CSD, but let the AI handle the complex math and coding, haha!

5.) The Use Case Currently, it’s a reliable safety net for beans with similar profiles to my Ethiopians. The goal is to eventually use it as a co-pilot for profiling unknown origins, providing a “second opinion” ~60–90 seconds early.

6.) Inspiration I simply asked Claude: “Is there a way to predict phase transitions using only my existing temperature logs, without adding new sensors?” It suggested the CSD approach (common in ecology and medicine) as it’s computationally light and doesn’t require massive training data so give it a shot!

Hope this clarifies things, and good luck with your Bullet! :beans:

2 Likes
7

^^ Great job for AI. Not the actual cleaning and conversion mind you, but asking it to help you create a script to clean and format the data would save you loads of time down the road.

Plus RoasTime now offers an API that would let you fetch the data from online and not need to export anything at all by hand.

1 Like
8

Thanks for those answers and again, good work!

I too once used ChatGPT to write me a (not coffee related) python program. lt took dozens and dozens of iterations to get the program to do what I wanted it to do, since I essentially have zero programming knowledge. However, it did work in the end.

It would be fascinating to see how the accuracy of your data would change, if instead of the thermal proxy of 190°C you could know the actual time stamp for FC.

In any case, I believe it is people like you that make Tokyo such an interesting and vibrant city!

1 Like
9

Hey I’m a data scientist lurker and I’m really interested in growing this dataset.

A couple ideas off the top of my head:

  1. If you want to build a generalizable model and not something that’s overfitted to Ethiopian origins, try incorporating a variety of roasts, including ones that don’t go 100% to plan, etc. The LLM integration is smart! Is there a RAG/MCP incorporated under the hood to make it useful? I’m thinking we’d need to compile roasting book knowledge into a set of agentic skill files, etc. and have these referenced with the specific implementation. I’ve been looking into a few sources for this where roasters have captured their notes for experiments in books for many years, etc.

  2. I’m interesting in hosting a serverless/snowflake DB setup/Google drive URL where anyone can upload their roasts for these types of projects/analysis, I believe there used to be artisancoffeealliance back in the day, but it’s no longer in use.

  3. You may consider using the direct .JSON export format within Artisan and simply parsing that. I think the .alog files are designed to be read easily into Artisan itself and .JSON is more of a standard data pipeline format that I could easily ingest.

Anyhow - I’m a future bullet owner so I’ve been browsing these pages to look for issues/trends (just waiting for my spouse to give the OK) but wanted to share interest in helping/expanding this.

2 Likes