Can AI Dial In Pour-Over Coffee? What It Can and Cannot Do Yet

17 min read · Updated September 15, 2026

Testing whether AI can pick a V60 recipe, run the dial-in, and brew the cup. What LLM recipes get right, where automated brewers stop, and the sensor that is still missing.

I gave an app the details of a light-roast Ethiopian natural: origin, producer, elevation, roaster, process, the roaster’s own tasting notes. A few seconds later I had a dose, a ratio, a water temperature, a grind direction and a target brew time.

Generating that is easy now. Any current language model will do it, and the answer will look plausible.

The hard question arrives after the first sip. The cup is a little hollow and finishes dry. What should I change, and how would the model know whether its last suggestion helped?

The short version

• Recipe generation is solved well enough. Turning bag metadata into a sensible starting point is something models do competently. Treat the output as a starting guess rather than an answer.
• Physical execution was solved without AI. Commercial machines have been running programmed pour-over recipes with computer-controlled water delivery for years.
• Adaptive dial-in works with a person in the loop. Give a model your brew history and ask for one change, and you get a real experiment instead of generic advice.
• Nothing in the loop can taste. In the one study that tried both, telling a model how the coffee tasted predicted liking roughly twice as well as giving it every number a machine can measure about the brew.
• The objective is personal. Research on consumer preference keeps finding clusters of people who want different things, so “optimize my coffee” is an underspecified request.

Four things get called AI coffee

Most arguments about this topic happen because four separate capabilities share one name.

A robot executing a programmed recipe is sophisticated automation with no intelligence in it. A model writing a recipe is intelligence that never touches water. The interesting systems are the ones connecting the two, and they all still have a person in the middle.

What an AI recipe actually is

BeanBench has a feature that collects everything the app knows about a coffee and turns it into a prompt.

Worth being precise about what this does, because it is unusual. BeanBench does not call a model. It builds the prompt and copies it to your clipboard, which is why the app’s own screen tells you that pasting sends the data to a third-party service. Your logs stay on your device and the app keeps its “Data Not Collected” privacy label, and you get to use whichever model you already pay for. It also means the same prompt works whether you brew on a V60, a Clever, or a machine the app has never heard of.

What comes back is a prior. The model has read a great deal about Ethiopian naturals and light filter roasts, and it uses that to land somewhere sensible in a parameter space with far too many dimensions to search by hand. Landing somewhere sensible saves an afternoon of flailing. Confusing it with knowing the answer is where people get into trouble.

Why the numbers sound more certain than they are

Ask a model for a brew temperature and you will get a number with a reason attached. Light roast, so hotter. Natural process, so cooler to protect the fruit. Anaerobic, so cooler still. The reasoning sounds mechanistic. Most of it is convention.

Take temperature. The most-cited controlled study brewed drip coffee at 87, 90 and 93C while adjusting grind and flow to hit the same strength and extraction yield, and found that temperature by itself had no appreciable effect on the sensory profile (Batali, Ristenpart & Guinard, 2020). Temperature is still a real lever at home, because when you change it you also change extraction. The point is that the effect runs through extraction rather than through some flavor property of 93C water. A model that says “brew this at 92C to preserve the volatiles” has flattened that into something that sounds settled. More on this in brew temperature.

Grind has the same problem in a different shape. A grind setting is a single number, but extraction depends on the whole distribution of particle sizes your burrs produce. A 2025 study found that treating a distribution as one representative size underestimated the time needed to reach 90%, 95% and 99% of extraction yield by up to 16.5%, 30.3% and 48.3% (Estevez-Sanchez et al., Journal of Food Engineering). Two grinders set to “medium” are not producing the same coffee bed. See grind size.

Water is the sharpest example, because the standard advice is wrong in a way that is easy to check. Magnesium brings out fruit, calcium adds body: an LLM will produce that confidently, and so will most of the coffee internet. The mechanism came from a computational chemistry paper, and when researchers measured organic acid extraction directly in 2024 they found little change at normal drinking-water mineral levels, with clear effects only around ten times those concentrations. Our own water guide already treats that story as unsettled.

Then there is everything a model never gets told. Pour height and jet thickness change how much the bed mixes, which a 2025 fluid dynamics study visualized directly. Your filter, your water, your kettle’s flow, how hard you swirl. See pour rate and agitation.

None of this makes the output useless. It means the precision of the answer should not be mistaken for confidence in it.

When someone actually tasted the cup

The clearest illustration of all this played out in public, in a Reddit thread, over about a day.

A developer built aiden-mcp, an unofficial MCP server that lets Claude scrape a roaster page, generate a brewing profile and push it straight to a Fellow Aiden brewer. It is built the right way round: model reasoning, plus structured priors built from 145 brewing profiles harvested from Fellow’s own published material, plus a constrained interface to a real machine. Rather than letting the model invent every number, it anchors them in what Fellow’s own people arrived at by tasting.

Then someone ran it on a coffee they knew well, a washed Pink Bourbon. Claude dropped the first steep from 207F to 201F to protect, in its words, the volatile bubblegum and floral top notes. The verdict after tasting:

The agent works flawlessly. But the brew profile provided by Fellow hits better that the adjustments that Claude suggested.

The developer’s reply explains why:

people who actually test are going to beat an AI’s first guess. your cup caught a real bug though […] the tool had a “protect florals, stay under 94C” rule that overrode everything else. your coffee proved it wrong for dense washed beans […] turns out the old “brew naturals several degrees cooler” folk wisdom isn’t real either. across all the drops profiles, washed and natural both sit at ~96C median.

One person tasting one cup was enough to falsify a rule that sounded like chemistry. Checking it against the actual profile data then killed the folk wisdom behind it, and the tool’s brewing logic was rewritten. The code now says so in as many words, noting that expert profiles run naturals as hot as washed coffees, and applies a single degree of adjustment instead of several.

The part I find instructive is what did not change. As of this writing the project’s README still advertises the original example, telling you the tool returns the principle that naturals lose volatile aromatics above 93C. The logic underneath was corrected months ago. The prose describing it was not.

That is the failure mode to watch for. AI explanations sound more settled than the evidence supports, and the writing around an AI system goes stale even while the system improves.

Hardware that pours the water

Executing a recipe precisely turned out to be the tractable part, and it was solved without any AI at all.

Poursteady has been selling pour-over robots to cafes for years. A moving gooseneck head delivers water in a computer-controlled spiral, recipes are written and edited by people, and a portal pushes them to machines across locations. Their smallest machine runs without a network connection. Nothing in their marketing claims AI, because nothing needs to. The problem they solve is a barista’s fourteenth cup of the morning not matching their first.

The newer category connects execution to a feedback loop. Cosori’s Juni, which went on sale on 10 September 2026 at $299.99, advertises exactly the closed loop this article has been describing: scan the bag, the machine builds a recipe, it brews, and you tell it how the cup was. Rate a brew “could be better” and it asks about sweetness, acidity, bitterness and body, then adjusts the stored recipe. Cosori calls it Taste Intelligence.

Every one of those claims comes from Cosori. The machine is five days old as I write this, there are no independent reviews or teardowns, and nothing public says what the “AI” consists of, whether the bag scan reads the label or matches a database, or whether your feedback follows a particular coffee or just the machine. Cosori has the loop drawn correctly. Whether it works is not yet established by anyone outside the company.

Both are worth understanding as one axis. Automation controls how precisely a recipe gets executed. Intelligence decides what the recipe should be. A machine can score well on one and not the other.

The missing sensor

Here is the BeanBench screen I reach for most, which supplies history rather than just metadata.

The instruction at the bottom asks for a single change and gives the reason for it. Asking for a single change is good experimental design. Changing one variable keeps the next brew interpretable, and the recent-attempts list lets the model reason over a trajectory instead of guessing from scratch.

Look at what the log contains, though. Grinder and setting, dose, ratio, brew time, drawdown, water temperature, filter. Every one of those describes what I did mechanically. Not one of them says whether the coffee was any good.

That gap has been measured. A 2026 study in npj Science of Food trained models to predict how much people liked a cup, using 118 consumers and 27 brews spanning three temperatures, three strengths and three extraction yields (Gunning et al.). The dataset is the same UC Davis consumer set behind the revised Brewing Control Chart, re-analyzed.

Tell the model how the coffee tasted and it explains roughly twice as much of the variation as giving it everything a machine can measure about the brew. The classification numbers look closer, 0.75 against 0.78, but that comparison flatters the instrumental model: the sensory version was tested on a real holdout set, while the instrumental one could not be, because the authors say plainly there were not enough data to generate one.

So taste is not a nice-to-have input. On the evidence available it is the most predictive thing you have.

There is a second problem underneath, which is deciding what better means. The revised Brewing Control Chart found consumer preference splitting into clusters that like different things (Guinard et al., 2023). The npj study found the same split, roughly half preferring dark chocolate and roasted notes, half preferring tea, florals and fruit. Optimize toward what? Maximum extraction, the roaster’s intended profile, your own liking? An agent needs an objective as much as any other optimizer, and yours is not the same as mine.

Claims to be careful with

• “AI-optimized coffee.” A 2025 paper applied reinforcement learning to pour-over and reported 90% accuracy (Bramantoro et al., PeerJ Computer Science). That figure is accuracy against the authors’ own simulator, built out of 3,600 simulated sequences generated from 10 real brewing observations on a single Sumatran coffee. Physical validation was one unblinded brew. The authors themselves flag convenience sampling and the risk of overfitting to the simulated environment.
• “Brew naturals cooler to preserve the fruit.” Widely repeated, and the one dataset of expert profiles anyone has checked shows washed and natural sitting at the same median temperature.
• Drawdown time as a target. A model that optimizes toward a 3:00 drawdown is optimizing an observation. Drawdown tells you the bed changed. Taste tells you whether the cup improved.
• “Scan the bag and get your perfect recipe.” Preference has learnable structure, at roughly R² = 0.24 from instrumental measurements on 27 brews. That is a real finding and a long way from inferring your ideal V60 recipe from a photo of a label.

What a useful AI coffee tool should do

The design implications follow from the gap above, and they apply to any tool in this space rather than to one app.

Capture the outcome as structured data. Overall liking, sweetness, acidity, bitterness, astringency, body and clarity, alongside free-form notes. This is the input the research says matters most and the one most brew logs omit.

Let the person state a goal. “More strawberry,” “less boozy,” “keep the sweetness but cut the dryness.” Without it, the optimizer has no objective function and defaults to somebody else’s.

Change one variable and say what you expect. A recommendation should read like a hypothesis:

Try Ode 5 and two thirds instead of 6. Keep everything else the same. Your last three brews held ratio and temperature constant, the finer one was sweeter, and the latest cup still finished hollow. This is a one-step test to raise extraction without changing strength.

Label where the advice came from. Your brew history, the roaster’s published recipe, an empirical profile prior, published research, or general heuristic. The aiden-mcp story is the argument for this: a recommendation tagged “folk wisdom, low confidence” would have been easy to discount before it cost someone a bag of Pink Bourbon.

But should we automate pour-over?

There is a question hiding under all of this. Suppose the closed loop works. Do we want it to?

Part of the appeal of pour-over is that it is stubbornly analog. You weigh the beans, grind them, heat the water, rinse the filter, watch the bloom rise, pour in slow circles, notice when the bed behaves differently than last time. Then you taste it and decide what to try tomorrow.

Viewed purely as an optimization problem, most of that is unnecessary human involvement. A machine holds temperature and flow better than I can. The variability that frustrates an engineer is part of what makes the hobby interesting.

Using AI to augment a craft is a different project from using it to eliminate one, and which one you are building decides more than the capability question does. Software that remembers my last thirty brews, notices that this coffee got sweeter every time I went finer, and suggests I try one more step tomorrow is the kind of help I want. Software that orders the beans, picks the recipe, brews the cup and quietly improves it while I am in another room has produced excellent coffee and removed the thing I liked doing.

Coffee is not special here. Navigation software gets us places without our ever learning the route. Cameras choose exposure so we never have to understand it. Sometimes that trade is wonderful. Sometimes the process was the point.

So the most interesting role for AI here is probably not full autonomy. Let software do what software is good at: remembering dozens of brews, finding patterns, retrieving information about a coffee, keeping experiments clean, proposing the next variable. Let the person keep tasting, interpreting, deciding and brewing, which is the part they signed up for.

The goal does not have to be “make the mathematically optimal cup for me.” It can be “help me understand how to make a better one myself.”

Run the experiment yourself

I am running a structured version of this and will publish the results. The protocol is here if you want to run it too.

Pick three coffees that behave differently: a clean washed light roast, a natural or experimental light roast, and something more developed. For each, establish a reference recipe, either the roaster’s or your own known-good one.

Then produce three candidates per coffee:

1. Generic AI. Give a model only what is printed on the bag. No gear, no history.
2. AI with context. Give it your grinder and setting, water, brewer, filter, dose and the coffee’s rest age.
3. AI with feedback. Start from the second recipe, then run two or three rounds where you brew, record how it tasted in structured terms, and ask for one change.

Hold everything else constant: same brewer, filter, water, dose and technique. Record pour schedule, total time and drawdown for every brew, and TDS if you have a refractometer. Resist the urge to treat extraction yield as the definition of a good cup.

Two details make the results worth having. Write down what the AI predicted the change would accomplish before you taste, so you can score its diagnosis rather than only its recipe. And taste the finalists blind, with someone else pouring them into unmarked cups. A simple “A or B” is more honest than pretending you can assign an 87 out of 100.

Then judge more than which cup won. How many brews did each approach need? Did the diagnosis match what you tasted? Did it change things that did not need changing? The plausible result is that AI gets you most of the way there from a standing start in one brew, and that experience still wins the last few adjustments. That would be a useful finding either way.

Track it in BeanBench

An AI suggestion is only as good as the history behind it, and the history is the part that evaporates by the next bag. Log the coffee, grinder setting, ratio, temperature, time, drawdown and how it tasted in BeanBench, and after a dozen brews you have something no published recipe can give you: what your grinder does with your water in your kitchen, on this coffee. That record is what turns a generic starting point into a real dial-in, whether the next suggestion comes from a model or from you.

From here, read grind size for the lever to reach for first, brew temperature for what the research supports, or sour, under-extracted coffee and bitter or dry coffee for diagnosing the cup in front of you.