Is gymflation real?

Investigating with R and LLMs

Chris Bowdon

2026-07-22

I’m going to show you tips and tricks on using LLMs with R. Hopefully you are here because you like R and data stuff. If you have an interest in exercise culture that’s even better, but not a requirement.

About me

By day I am CTO at Polecat Intelligence, where we use AI to extract structured reputation risk insights from online media. By night I fool around with more or less the same stuff, for free.

Gymflation is nothing to do with Polecat, but we use the techniques here regularly.

I would add that at Polecat we primarily do our data science work in Python, but personally I have become a big fan of R so that’s what we’re going to use today. I’m also a fan of resistance training, and that’s what opened my eyes to a new-but-familiar phenomenon, gymflation.

Blog post with all the code and data: https://cbowdon.github.io/posts/gymflation

Premise

Social media is distorting the perceived average strength level.

Much like it is distorting beauty standards, success standards, relationship standards, politics, etc. Quicker to list fields that haven’t been distorted by social media.

What is gymflation?

• An excuse to show you some LLM techniques.
• A phenomenon connected to social media’s negative effects on self-image, which is increasingly leading to mental health issues such as body dysmorphia.
• Mostly the former though.

One of the fascinating things over the last three years has been how traditional machine learning techniques have evolved and become accessible to people who wouldn’t normally consider natural language processing and computer vision to be tools they can call on. Although I’m personally rather interested in online gym culture - which I hasten to add isn’t entirely bad, there is some positive information and motivation sharing - in this talk it’s more of a platform to let us explore how you can make good use of LLMs in a research project.

Comparison to superhero inflation

“When I grow up, I want to be as strong as Batman” is less achievable now than it was in the 60s.

Batman demonstrates the closely related idea “superhero inflation”.

Body dysmorphia and the ill-effects of social media are real and growing problems, but I don’t want to overstate my credibility in that area - I’m not a social scientist, just an interested amateur.

However it doesn’t strike me as controversial to say that some cultural standards have changed rapidly in recent times.

Plan

How can we investigate this?

Measure if feats of strength reported in online videos are increasing.

Taking a narrow definition of strength: deadlift personal record (PR) videos on YouTube.

Questions:

1. Is the average reported deadlift PR weight increasing over time?
2. Are the number of reported heavy deadlift PRs increasing over time?

• Deadlifting is the method that lets one lift the most weight, so it’s a point of pride for many lifters.
• It goes like this - the bar starts on the floor, you bend over, and you straighten up to lift the bar to hip height. A lot of muscles get involved in this, primarily your erector spinae (the long back muscles on either side of your spine) and the glutes (buttocks), and also your quads (thighs). It’s important to keep your back straight to avoid injury.
• Typically people will report the maximum weight that they can lift for one repetition. That’s known as your One Rep Max, or 1RM. Your best ever is your personal record, or PR. A rule of thumb is that after a few years of serious training, someone would be able to deadlift over twice their bodyweight.
• I say “questions” rather than “hypotheses” because we’re not doing science here, we’re playing.

Steps

• Scrape the YouTube API for 10 years of deadlift personal record (PR) videos with httr2
• Use structured responses to extract the lifted weight with an LLM
• Evaluate the quality of our extraction and improve it with In-Context Learning (ICL)
• Use a multimodal model to judge the lifter’s gender
• Make extensive use of caching so errors don’t set us back
• Plot our results with good old ggplot2

Instagram, TikTok and YouTube are all popular among the lifting community (and probably many more) but YouTube is relatively open with its data, making it our best choice.

Data gathering

YouTube API

We can use httr2 for this.

library(httr2)

req <- request("https://youtube.googleapis.com/youtube/v3/search") |>
1  req_cache(".cache/httr2") |>
  req_url_query(
    part = "snippet",
    q = query,
    type = "video",
    maxResults = 50,
    duration = "short",
    region = "UK",
    published_after = published_after,
    published_before = published_before,
    key = YOUTUBE_API_KEY
  ) |>
  req_headers(Accept = "application/json") |>
  req_timeout(30)

2req_perform(req) |>
3  resp_body_json(simplifyVector = TRUE)

1

Client-side caching saves you from wasting time or request quota.

2

Other useful methods include req_dry_run and req_perform_parallel.

3

Getting data back as a dataframe is very convenient, so I recommend simplifyVector = TRUE.

Caching is always smart. If data is hard to get, it’s also wise to save data obsessively, because at some point you’ll accidentally nuke your cache. In this case I hit YouTube’s 24 hour quota quite quickly and had to spread collection over several days.

Data

id.videoId	publishedAt	channelTitle	title	description	thumbnails.high.url
tWnuZ1i_JuY	2019-07-08T20:34:15Z	All Out Performance	[PERFORM] Beltless Deadlift PR	Coach Ash hit a new beltless PR on his Deadlift during this session! Throughout the AOP Programming we focus heavily on …	https://i.ytimg.com/vi/tWnuZ1i_JuY/hqdefault.jpg
dv1IFeprYlM	2022-02-15T16:40:00Z	All Gains No Pains	485lbs deadlift PR		https://i.ytimg.com/vi/dv1IFeprYlM/hqdefault.jpg
qIgSChVszHg	2019-02-17T08:45:15Z	Matt Schaub	605 Deadlift PR at 20 years old and 205 pounds		https://i.ytimg.com/vi/qIgSChVszHg/hqdefault.jpg
awfZk6d3wM0	2024-02-26T17:09:11Z	Grzegorz Heinze	deadlift PR 363,5kg bw120 21y.o.		https://i.ytimg.com/vi/awfZk6d3wM0/hqdefault.jpg
53YV4xy7tkE	2016-11-19T07:56:30Z	The SideStep	500lb Deadlift PR		https://i.ytimg.com/vi/53YV4xy7tkE/hqdefault.jpg

Table 1: Sample of the raw data from the YouTube API.

Regular expressions wouldn’t be sufficient here…

A reasonable question is whether we could use regular expressions, regexes, to extract the weights. There is often a pattern after all. However, in practice it’s clear that people are mixing in their bodyweight and age, so it would be pretty error prone. Luckily in 2026 we have a new option.

Model 1: fact extraction

Using an LLM to extract the weights from the messy text.

Once upon a time, one would train either a sequence-2-sequence model or a small generative transformer, but now the great big NLP box in the sky provides. We no longer need to fire up Python, or even have a GPU.

At this point it’s good to check familiarity. Is everyone aware that LLMs are not only chatbots, but can be used programmatically via HTTP APIs? In dead simple terms, you can send a message to OpenAI’s servers, and they will run ChatGPT on it and send the answer back. OpenAI isn’t the only AI lab in town of course, and in the examples that follow I’m mostly going to use an open source (free) model that’s small enough to run on my laptop.

We’re going to use the R library Ellmer. We will make use of structured responses to ensure that we don’t have to parse the response text ourselves, it’s guaranteed to be formatted in the JSON object of our choice.

Structured responses

library(ellmer)

1LLM_SERVER_URL <- "http://localhost:8080/v1"

system.prompt <- "The user will provide the title and description of a YouTube video. If they describe a weight being deadlifted, you must extract the weight that was deadlifted, with the unit, and the number of repetitions.

Note that the deadlift world record is currently 510kg/1122lb.
Return only a JSON object with keys:

- `weight` (numeric)
- `unit` (kg, lb or NA)
- `reps` (numeric, assume 1 if not provided). 

Do not perform unit conversion.
Return NA as the unit if the description doesn't mention a weight deadlifted or the unit isn't clear."

extract_dl_weight_model <- function() {
  chat_openai_compatible(
    LLM_SERVER_URL,
2    model = "mistralai/ministral-3-3b",
    credentials = function() "", # not used - local model
    params = params(max_tokens = 50), # don't generate more than we need
    system_prompt = system.prompt
  )
}

extract.dl.weight.type <- type_object(
  weight = type_number("The weight deadlifted, as a number."),
  unit = type_enum(values = c("kg", "lb", "NA")),
  reps = type_integer("Number of repetitions (1 if unspecified)")
3)

1

Local caching proxy

2

A small open source model, running on my laptop via LM Studio

3

The response structure definition

That local caching proxy isn’t a technological marvel: it checks if I’ve made a request with the same model and inputs before. If not, it sends it off to the remote server and saves the response to disk, wheras if I have it will just copy back the saved response from last time. This saves time/money/energy.

The model is from the French lab Mistral, the only major AI lab with an HQ in Europe unless you count Google DeepMind. They make their smaller models available for free and if you have enough of a GPU on your computer you can run it yourself. That’s nice because you’re not paying anything except your electricity bill, and you get complete privacy. It also lets tinkerers play with the innards of a model and do cool stuff: we can thank open source models for a lot of innovations.

Structured generation is dead simple conceptually: at each generation step, instead of sampling from all possible tokens, sample only from tokens that are legal according to your schema. Theoretically any grammar is fine, but in practice everyone is using JSON schema.

If we only prompted the LLM to return JSON in our desired format, but didn’t restriIct its outputs, it would mostly return the right format. Structured generation makes this reliable. It’s usually best to keep the format instructions in the prompt though, so we get sensible probabilities on the legal tokens.

Example structured response

extract_dl_weight_model()$chat_structured(
  "Title: 665 lbs deadlift at 188 lbs bodyweight #deadlift #pr #powerlifting #powerlifter #usapl #ipf #shortsfeed\nDescription: ",
  type = extract.dl.weight.type
) |>
  as_tibble() |>
  kable()

weight	unit	reps
665	lb	1

• In this case we need to perform 2 conversions: Imperial -> Metric, and Epley 1 rep max calculation.
• An LLM is smart enough to do an imperial to metric conversion for you, but rather than placing additional cognitive load on the model (which will cause it to make errors and/or waste tokens) we might as well give the LLM a smaller task and do this trivial calculation ourselves.
• That looks right, but to what extent can we trust this?

Evaluating our model

• AI is jagged intelligence: screws up in unexpected ways
• Need to measure its performance
• Build high-quality test set and score accuracy (dev + test) ¹
• This model so far: 73% accurate in its extractions
• Let’s open the model optimisation toolbox!

The most important thing is to evaluate the model on your task. Since in 2026 your “model” is a few lines of prompt text, the evaluation is the most valuable asset you have. And indeed, exciting systems exist that will generate optimal prompt text for you, so please don’t treasure a few lines of hand-crafted prompt. The evaluation dataset is the gold.

One of the techniques I considered showing you was getting a very large model to annotate your test set. But it’s TURTLES ALL THE WAY DOWN, because you need to be confident in the large model’s accuracy first.

A quick audience check, are you familiar with the concept of a dev set and a held out test set? This is worth knowing if you intend to try and optimise a model. The short version is that you split your dataset into two parts: a dev(elopment) set and a test set. Do initial assessments and iteration on the dev set, but keep the test set out of sight until you want to stop and score your final model. That way you avoid overfitting, in other words you avoid making optimisations that don’t generalise.

1. Manually annotated

In-Context Learning (ICL)

extract_dl_weight_model <- function(turns = list()) {
  chat <- chat_openai_compatible(
    LLM_SERVER_URL,
    model = "mistralai/ministral-3-3b",
    credentials = function() "", # not used - local model
    params = params(max_tokens = 50), # don't generate more than we need
    system_prompt = system.prompt
  )
  chat$set_turns(turns)
  chat
}

example_turn_pair <- function(title, description, weight, unit, reps) {
  list(
    UserTurn(list(ContentText(
      interpolate("Title: {{title}}\nDescription: {{description}}")
    ))),
    AssistantTurn(list(ContentText(
      interpolate(
        "{\"weight\":{{weight}}, \"unit\":\"{{unit}}\", \"reps\":{{reps}}}"
      )
    )))
  )
}

A.k.a. “few-shot learning”, the idea is you condition the LLM on example inputs and outputs.

Here I’ve hand-crafted some examples based on dev failures.

New result: 92% extraction accuracy on test.

turns <- c(
  example_turn_pair(
    title = "deadlift PR 220 @ 165 bodyweight",
    description = "hit this at my meet",
    weight = 220,
    unit = "NA",
    reps = 1
  ),
  example_turn_pair(
    title = "NEW PR 585",
    description = "new deadlift personal record",
    weight = 585,
    unit = "NA",
    reps = 1
  ),
  example_turn_pair(
    title = "NEW PR 330x3",
    description = "",
    weight = 330,
    unit = "NA",
    reps = 3
  ),
  example_turn_pair(
    title = "180kg x 3 deadlift PR",
    description = "81kg 18 years old.",
    weight = 180,
    unit = "kg",
    reps = 3
  ),
  example_turn_pair(
    title = "100kg/220lb deadlift PR",
    description = "smashed it",
    weight = 100,
    unit = "kg",
    reps = 1
  ),
  example_turn_pair(
    title = "365 lb Deadlift PR @ 165 lbs",
    description = "Christal hitting a new deadlift PR @ 365 lbs, beltless. And before anyone says anything about her form, her deadlift PRs have ...",
    weight = 365,
    unit = "lb",
    reps = 1
  )
)

The score on the dev set was 98%, which is awesome, but highlights why we split.

By the way, with current reasoning models ICL is sometimes detrimental because the LLM can over-condition on the examples at the expense of doing additional reasoning of its own. For this reason it’s always necessary to evaluate.

First look at the data

Figure 1: Deadlift PRs reported by YouTube users over time. World record lifts are points overlaid in orange. The dashed horizontal lines are round-number Imperial weights (100-1000lbs).

• Pleasingly normal distribution
• Some suspicious reports at the high end
• Expect some clumping on round numbers, similar to the 6ft height effect
• But hold on…

Model 2: image classification

Male and female lifters have different strength distributions. Changes in one could mask changes in the other.

This is a big and obvious potential confounder, so we should investigate further.

For what it’s worth I also took at a look at different lifting styles. The choices are conventional and sumo, the latter being where you spread your legs wider than your arms so your back is more upright and your legs do more of the work. Debate rages on in the lifting community, but I didn’t find any difference.

Image classification model

gender.classifier.prompt <- "The user will provide a YouTube video thumbnail of a deadlift PR. You must predict the gender of the person lifting the weight using the image and the video metadata (channel and title).
  Respond with `M` if the person appears male or `F` if the person appears female. If no real human is visible enough or if there are multiple people lifting the weight, respond with `NA`.
  Return your answer in a JSON object with a single key `gender` with value `M`, `F` or `NA`."

predict_gender_chat <- function(model = "mistralai/ministral-3-3b") {
1
  chat_openai_compatible(
    LLM_SERVER_URL,
    model = model,
    credentials = function() "",
    params = params(max_tokens = 1000),
    system_prompt = gender.classifier.prompt
  )
}

predict.gender.type <- type_object(
  gender = type_enum(values = c("M", "F", "NA"))
)

img_prompt <- function(row) {
  list(
    sprintf(
      "YouTube Channel: %s\nVideo title: %s",
      row$channelTitle,
      row$title
    ),
2    content_image_file(row$image.path)
  )
}

1

Ministral 3 3B is capable of understanding images too.

2

We can provide both text and an image file in a single turn.

Since Mistral’s output is still text, we can use structured responses again.

Some models can also take audio and video input, and of course some models can output images, audio, and video. There are a lot of possibilities. The cost in tokens of these inputs can be a bit arcane though, so it’s good to measure.

Example usage

prompt <- img_prompt(df.weights.imgs[1, ])
chat <- predict_gender_chat()
chat$chat_structured(
  prompt[[1]],
  prompt[[2]],
  type = predict.gender.type
)
#chat$get_tokens()

Evaluating our image model

• Another cycle of dataset annotation, evaluation and optimisation.
• This time I’ve vibe-coded an annotation UI.

• Though the code for this UI is absolutely disposable, it’s absolutely worth your time designing a UI that minimises cognitive load, is efficient to manipulate, and doesn’t lead to mistakes.
• There’s really no substitute for getting to know your own data by the way. It’s absolutely worth your time. Unless you were intimately involved in collecting the data, it will surprise you. And more than that, I feel it’s only when you get into the data that insights arrive. For example my naive version of this image model was providing only the image - isn’t that enough? Well it turned out that often the image was unclear but the channel name or the title was enough to disambiguate. I also found that some of the images weren’t actually real people, they were anime people, so I had to steer the model around that.
• I should mention that an improvement on my approach here would be to have multiple judges, check their agreement, and perhaps have multiple iterations of refining the coding guidelines and labelling the data.

Model search

The model scores 77% accuracy on the balanced evaluation set. Let’s see if money can buy better results.

chat_or <- function(model) {
  chat_openrouter(
    model = model,
    system_prompt = gender.classifier.prompt,
    api_headers = c(
1      `X-OpenRouter-Cache` = "true",
      `X-OpenRouter-Cache-TTL` = 86400 # can cache up to 24 hours
    ),
    api_args = list(
2      reasoning = list(enabled = TRUE)
    )
  )
}

3chat.gem <- chat_or("google/gemini-3.1-flash-lite-preview")

prompt <- img_prompt(df.weights.imgs[2, ])
chat.gem$chat_structured(prompt[[1]], prompt[[2]], type = predict_gender_type)

1

chat_openrouter doesn’t accept base_url for the proxy, but we can enable experimental response caching from OpenRouter itself.

2

We must explicitly enable reasoning.

3

The best model in our budget.

Gemini 3.1 Flash Lite Preview scores 87% on the evaluation set, huzzah. But will it cost the earth?

chat_cost <- function(chat) {
  last.turn <- chat$last_turn()
1  last.turn@json$usage$cost
}

1

Ellmer’s chat$get_cost() doesn’t always work, but you can get at it via the raw JSON.

The predicted cost was approx. 2 USD, which is good because my budget was $10 and I expected to screw up at least 4 times.

I’ve skipped over the bit where I evaluated a range of models. It’s fairly mechanical though: you go on OpenRouter, you find the top-scoring models in your price range, and try them all. I also evaluated a model from MiniMax (Chinese open source) and a slightly-too-expensive model from Google as a reference point.

One big tip: be hygienic about your OpenRouter API keys. Use a distinct key for each task so that you can track (and cap) your spending.

Second look at the data

Figure 2: The distribution of deadlift 1RM weights by gender - clearly different.

Figure 3: Female lifters are still the minority, but have arguably improved relative to male lifters.

Honestly there’s not a huge amount to say here - the distributions look largely as you’d expect, and there is this arguable trend but I wouldn’t too put much weight on that.

This was really about the journey rather than the destination. These charts just reassure us that we did a decent job.

Summing up

We looked at:

• Some tricks for scraping data from the YouTube API with httr2
• Using structured responses with Ellmer to extract data with LLMs
• How to use ICL to improve our LLM extraction model
• How to do image classification with VLMs
• Building an evaluation set with a vibe-coded annotator UI
• Finding a better model on OpenRouter
• I hope you weren’t too invested in the gymflation idea itself

Blog post with all the code and data: https://cbowdon.github.io/posts/gymflation

Thank you to the remaining audience members, and thank you to Jeremy and Datacove for tirelessly organising these events!