Category: Artificial Intelligence

We can all build our own tools now: what Claude and GPT-6 Astra mean for researchers (and some apps worth a look)

Back in March 2011 I wrote a short post about Google Labs’ anatomy tool. At the time, being able to rotate a 3D human body in a web browser felt like science fiction, and it had taken one of the biggest technology companies in the world to build it. Fifteen years later, a single developer released an open-source anatomy explorer that takes the human body apart into 2,234 individually selectable pieces — two days after the AI model she used to build it became available.

That, in one sentence, is what this post is about.

Over the summer I have written here about the tools I have been building with AI: a lactate threshold analyzer, a ten-year triathlon heat-strain study run end-to-end with AI, a systematic review on lactate supplements and a rebuilt football injury dashboard. None of them needed a development team. What has changed in the last couple of weeks is that it is no longer just me, and no longer just one company’s tools. Researchers, clinicians and educators everywhere are shipping genuinely useful applications, and some of them are very good indeed. So I wanted to pull together what has happened with the models, show you a few of the apps that caught my attention, and be honest about where I think we need to be careful.

How it used to work

For most of my career, getting a bespoke tool built followed the same script. You wrote a specification. You found a developer, or a budget, or both. You waited. You tested what came back and discovered the developer had misunderstood the science. You waited again. Many good ideas never made it past the specification stage, and many of the tools that did were abandoned the moment the grant ran out or the developer moved on.

That script has been torn up. The distance between “I wish I had a tool that did this” and a working link you can send to colleagues is now measured in days, sometimes hours.

What changed this summer

On the Anthropic side, the Claude 5 generation arrived one tier at a time rather than in a single big launch: Claude Opus 4.8 at the end of May, Claude Fable 5 and Mythos 5 on 9 June, Sonnet 5 on 30 June, Opus 5 on 24 July, and Fable 5.1 and Mythos 5.1 on 1 September. Opus 5 is what I used for the lactate review, and the combination of its price and a one-million-token context window is what makes it practical to keep a whole codebase, a dataset and a protocol in view in a single working session.

Fable 5.1 and Mythos 5.1 are the same underlying model with different safeguards: Fable is available to everyone, while Mythos is restricted to vetted cybersecurity and life-sciences organisations. The number that caught my eye was on Terminal-Bench-Science, a benchmark of agentic scientific research tasks, where Fable 5.1 scored 52.6% against 24.7% for Fable 5 only three months earlier. These are vendor-reported benchmarks, so treat them as such, but a doubling in a quarter is not nothing. Cache reads also became 75% cheaper, which sounds boring but matters a lot when an agent spends a long build session re-reading the same files.

The models are only half the story, though. Claude Code, Cowork, Claude Design and artifacts that can store data mean the output of a conversation is no longer a chunk of code you have to assemble yourself — it is a working tool you can open, test, share and keep improving.

On the OpenAI side, GPT-6 Astra was released on 3 September, first to a limited set of organisations and then to ChatGPT Plus, Pro, Business and Enterprise users and the API over the following days. OpenAI pitches it as state of the art for computer use, coding and scientific work. It is also the first OpenAI model to reach the “Critical” cybersecurity threshold in its own Preparedness Framework, which is why the rollout was staged — more on that later. The other piece worth knowing about is ChatGPT Sites, in public beta since July, which builds a web app from a conversation and publishes it straight to a live chatgpt.site address with the hosting included. At launch it was not available in the EEA, the UK or Switzerland, so not everyone reading this will have it yet.

Summer 2026: frontier model releases and the tools built with themAnthropic (orange) and OpenAI (teal) releases, May–September 2026, against examples of tools shipped in the same windowFable 5 / Mythos 5access paused(US export controls)Frontier model releasesTools shipped (examples)Claude Opus 4.8Claude Fable 5& Mythos 5Claude Sonnet 5Claude Opus 5Claude Fable 5.1& Mythos 5.1GPT-6 AstraLactate ThresholdAnalyzerTen-year triathlonheat-strain studyLactate supplementsystematic review(Opus 5)Football injurydashboard rebuildTesla Model Xexploded view(Astra)Human Atlas2,234 meshes(Astra)Model release → public 3D anatomy app: 2 daysJun 2026Jul 2026Aug 2026Sep 2026

The summer in one picture: model releases on top, tools shipped underneath. The gap between GPT-6 Astra becoming available and a public, open-source 3D anatomy explorer built with it was two days.

The cost of trying an idea has collapsed. The cost of being wrong has not.

Four tools worth a look

Human Atlas: the body in 2,234 pieces

human-atlas-seven.vercel.app · code on GitHub

This is the one I opened this post with. Developer Ashe Magalhaes had just used Astra to build an “exploded view” of a Tesla Model X in 334 pieces, and then, after joking online about whether it would be weird to do the same with a body, did exactly that. Human Atlas takes the BodyParts3D adult male reference apart into 2,234 selectable meshes across 15 anatomical systems, with 3,432 searchable named structures. You can rotate the body, isolate a single structure, switch systems on and off, and spread the whole thing out into an inventory of every visible piece. It is built with React and Three.js, the code is MIT-licensed, and the anatomy data keeps its own CC BY 4.0 licence.

What impressed me most, though, was not the rendering. It was the README. It tells you what was validated (mesh data, search, layouts on desktop and phone screens, tap-versus-drag handling), what was not tested (performance on physical devices and real multitouch hardware), and that it is an educational explorer, not a diagnostic or surgical tool. That is exactly the standard I would like to see from anyone publishing an AI-built tool.

Human Atlas: 2,234 BodyParts3D meshes in an exploded view, running in the browser with nothing to install.

Immediately after, another developer deployed the female model.

Someone else today deployed the skeleton

Portal Tau: clinical research methods made interactive

investigaciontau.com · Portal Tau

Tau: Investigación Clínica y Epidemiológica is Dr Joshuan J. Barboza’s Spanish-language platform for training researchers in systematic reviews, research methods and scientific publishing. Its companion Portal Tau shows what one researcher-educator can now put online. There is a Journal Match tool that scores how well your manuscript fits across 32,193 journals using Scimago, DOAJ and OpenAPC data; an explorer comparing the publication fees journals advertise with what institutions actually paid; a ten-module evidence-based medicine calculator; and a clinical trials simulator.

The simulator is the piece I would use in teaching. It runs phase I dose-escalation designs participant by participant — BOIN, Keyboard, CRM, the classic 3+3 and accelerated titration — as well as phase II designs (Simon, Gehan, Bayesian and randomised), and then simulates thousands of trials with Monte Carlo methods. Anyone who has tried to explain to a room of students why the 3+3 design is inefficient will know that running a thousand simulated trials in front of them does more than any slide ever will. And the whole suite sits on free static hosting: no server bill, no IT department.

The clinical trials simulator in Portal Tau: designs that usually live in textbooks, made interactive.

Shoulder Atlas: the examination in motion

shoulder-mechanics-atlas.geraldmd.chatgpt.site

If I had to put one of these in front of physiotherapy and sports medicine students tomorrow, it would be this one. Shoulder Atlas animates 12 clinical examination tests on a 3D right shoulder: empty can (Jobe’s), full can, Neer’s, Hawkins–Kennedy, painful arc, resisted external rotation, lift-off (Gerber’s), belly-press, Speed’s, Yergason’s, cross-body adduction and passive external rotation.

Each test plays out in stages. For the empty can, you watch the arm elevate in the scapular plane, the thumb turn down, and the examiner apply resistance, with live readouts of arm elevation, humeral rotation and elbow flexion. Separate overlays show passive guidance, examiner resistance and patient effort, and the target structures light up — supraspinatus and the subacromial region, in this case. Alongside the animation you get how to perform the test, what it loads, what counts as a positive finding and how to interpret it, with links to Stanford Medicine 25, the AAFP and ShoulderDoc.

Two things make it a particularly good example for this post. The first is where it lives: a chatgpt.site address, which is where ChatGPT Sites hosts what it builds, so it went from conversation to public link without anyone configuring a server. The second is its “About the model” panel, which is a small masterclass in honest scoping. Bones and muscle surfaces come from BodyParts3D; the bursa, capsule and tendon paths are simplified overlays; scapular movement is illustrative; there is no collision, force, tissue-strain or pain solver; and the angles describe the animation, not measured patient motion. It calls itself a teaching prototype, not a validated diagnostic simulator, reminds you that no single test confirms a diagnosis, and says plainly that instability and labral tests are not in this first version. I have seen commercial products that are a lot less candid.

Shoulder Atlas: Tests can be animated.

What these tools have in common

The hard part is no longer the code. In everything I built this summer, getting something to render was never the problem. The work was deciding which method to use, what to label as an estimate rather than a measurement, and what the tool should refuse to tell you. The science lives in the specification. Someone who understands why a modified Dmax threshold differs from a fixed 4 mmol·L⁻¹ one will write a far better specification than a developer who does not — and now that person can build the tool themselves.

Open data is doing a lot of quiet heavy lifting. Human Atlas and Shoulder Atlas both exist because BodyParts3D is openly licensed. Portal Tau works because Scimago, DOAJ and OpenAPC publish their data. The models get the headlines, but without open datasets they would have very little that is useful to build on.

The expert can build exactly what their practitioners need. A commercial product is designed for the average user. A tool built by someone in the field can encode the exact protocol, the exact caveats and the exact outputs a particular group needs — and be fixed the same afternoon someone spots a problem.

Being honest about limits is becoming the marker of quality. When building is cheap, the tools worth trusting are the ones that tell you what was checked, what was not, and what they are not for.

Where I would be careful

I am enthusiastic about all of this, but it would be a strange post from me if it did not come with caveats.

  • Plausible is not the same as correct. In the lactate review, the AI produced a chemistry figure showing the wrong mirror-image form of the molecule, and it looked perfectly fine. Apps fail in exactly the same way: a chart that renders is not a chart that is right. Every calculation in a tool should be checked against values worked out independently, by hand if necessary.
  • Educational is not clinical. The moment a tool is used to inform the diagnosis or treatment of a specific patient or athlete, it is in regulated territory. The best examples above say explicitly that they are for education. That line needs to stay bright.
  • Data protection does not get faster just because development does. Identifiable athlete or patient data should not go into a quickly deployed web app, or into a prompt, without the same governance you would apply anywhere else.
  • Security matters more, not less. The same capabilities that let a model build an app let it find the weaknesses in one. OpenAI staging Astra’s release because of its cyber capabilities, and the safeguards Anthropic layers on its Mythos-class models, should remind us that something deployed in an afternoon has probably not been hardened.
  • Tools that are easy to build are easy to abandon. Dependencies change underneath you — my own football dashboard showed a blank page for some people until I stopped it relying on an external charting library. Access to the models can change too: in June, Anthropic suspended access to Fable 5 and Mythos 5 for around three weeks to comply with US export controls before restoring it. Keep your code, your data and your exports somewhere you control.

In conclusion

A year ago, most of the tools in this post would have needed a team, a budget and several months. Now they need a researcher with a clear idea, a good specification and the discipline to test what comes back. And this is true whether you work with Claude or with ChatGPT — the capability is no longer tied to one company.

I do not think the people who benefit most will be those who build the most apps. It will be those who specify carefully, validate against known answers, write down what they have not tested, share their code, and keep themselves firmly in the loop. So my encouragement to colleagues is simple: build the tool you have always wished existed, put it online, be honest about its limits, and invite people to break it.

And if you have built something along these lines in sports science or sports medicine, send it my way. I would love to feature a few more.


Links mentioned in this post

Model release dates and benchmark figures come from Anthropic and OpenAI announcements and contemporaneous coverage; benchmarks are vendor-reported. Tool descriptions are based on the public sites and repositories as of 11 September 2026. I have no affiliation with any of the third-party tools mentioned. This post was drafted with the help of Claude and edited by me.

Rebuilding the Football Injury Dashboard: Adding Transfermarkt Data for the 2026/27 Season

The 2026/27 season is a few matchdays old, which is exactly the point in the calendar when injury counts start climbing. It seemed a good moment to go back to the European football injury dashboard I put together earlier in the year and deal with something that had been bothering me about it.

The original version had a structural weakness. Its month-by-month figures were not measurements. The Howden Group Men’s European Football Injury Index — the best free source covering the top five leagues — publishes one total per season, not one per month. To draw a monthly curve I had been distributing those annual totals across the year using the seasonal distribution reported in the UEFA Elite Club Injury Study. That gives a defensible shape, but every individual month was an artefact of the model rather than a count of anything. If you had asked the chart whether September 2023 was worse than September 2024, the answer would have been decided by the annual total, not by what happened in September.

So I added a second dataset alongside it, and let the reader choose which one they are looking at.

Two datasets, two different questions

The dashboard is here: footballinjuries.tiiny.site. A toggle at the top switches between the two sources. They answer genuinely different questions, and I have tried to make the distinction obvious rather than burying it in a footnote.

  • Season pattern — estimated monthly counts across seven leagues and five seasons, showing when in the year injuries cluster. Good for shape, approximate for magnitude.
  • Injured right now — a real count of every player listed as injured on a given date, from Transfermarkt. Good for who is actually missing, useless as a season total.
Line chart showing estimated monthly injury counts across seven European football leagues for the 2026/27 season, peaking in September
The seasonal view. The September peak is the most consistent feature in the whole dataset — players return from the summer break, fixtures arrive quickly, and bodies that have not been at match intensity for weeks are asked to perform. A second, smaller rise comes in April as accumulated load tells.

The Transfermarkt layer

The new view collects every player listed as injured on Transfermarkt‘s injury pages for the Premier League, Bundesliga, La Liga, Serie A, Ligue 1, Eredivisie and Liga Portugal. On 28 August 2026 that came to 257 players. These are individual records — a named player, his club, and what is reported to be wrong with him — not a figure derived from anything.

Stacked bar chart showing players currently injured across seven European leagues on 28 August 2026, coloured by injury type
Players injured across the seven leagues on 28 August 2026. You can click into any league to see it club by club.

The Bundesliga stands out with 66 players out, against 15 in Ligue 1 — though before reading anything into that, note that squad sizes, fixture load and how much press attention a league receives all feed into these numbers. That last factor matters more than it might appear, and it leads directly to the caveats.

Where this data is weak, and why I have said so on the page

Transfermarkt injury records are compiled from press reports, not club medical records, and that has consequences worth stating plainly.

A snapshot over-represents severe injuries. A cruciate ligament rupture stays visible on the page for months; a grade one hamstring strain disappears within a fortnight. The injury mix in the chart is therefore more severe than the mix of injuries a league actually sustains. This is straightforward survivorship bias and it cannot be corrected without incidence data.

Roughly a third of records name only a body part. “Knee injury”, “ankle problems”, or simply “unknown injury”. I could have forced these into a category and produced a tidier chart, but that would be inventing precision that is not in the source. They appear as Not specified instead. In the Eredivisie this accounts for 32 of 56 records — a striking difference in reporting practice rather than in injury patterns, and one that is itself interesting.

These are counts, not rates. There is no exposure denominator — no adjustment for minutes played — so none of this is comparable with the injuries-per-1000-hours figures the epidemiological literature reports. For that you need the UEFA Elite Club Injury Study or club data, and this dashboard is not a substitute for either.

The Eredivisie and Liga Portugal are also absent from the Howden report entirely, so their seasonal estimates lean on published injury-rate research for comparable leagues and should be treated as softer than the other five.

Other changes

Two smaller things. The dashboard is now written for a general reader rather than for me — plain-language injury categories, an explainer at the top, and a summary underneath the chart that rewrites itself as you change the selection. It also now states honestly how solid each season is: 2022/23 to 2024/25 are confirmed by Howden, 2025/26 has finished but is awaiting the December 2026 report, and 2026/27 has barely started and is labelled as a projection rather than a record.

The other change is invisible but was the reason several people saw a blank page: the chart previously loaded its plotting library from a CDN, and if that request failed — restricted network, content blocker, poor connection — the result was an empty rectangle with no explanation. It now draws its own SVG with no external dependencies at all. Nothing is loaded from anywhere. It works offline.

What next

The obvious next step is real month-by-month history rather than estimates. Transfermarkt does hold this — every individual injury record carries a start date — but assembling it means collecting player-level histories across seven leagues and several seasons, which is an overnight job rather than a page fetch. I have the pipeline written using the worldfootballR package; it is a matter of running it and validating what comes back. If it holds up, the estimated monthly figures get replaced with counted ones and the weakness I described at the top of this post disappears.

As with the triathlon dashboard, this is a living project and I would rather it be scrutinised than taken on trust. Have a look at the dashboard and tell me what is wrong with it, or what you would want to see next.

Seasonal estimates derived from the Howden Group Men’s European Football Injury Index (2024/25 edition, published December 2025) and the UEFA Elite Club Injury Study. Current-injury figures collected from Transfermarkt on 28 August 2026 and filtered to clubs competing in each league. Injury classification from free-text labels is approximate. These are counts without an exposure denominator and should not be read as incidence rates.