Railway's Viral 82% Claude Figure Is From Older Models

If your plan leans on the claim that Claude Code picks Railway for 82 percent of Python apps, check the model behind it. In Amplifying's February test, Railway took 82 percent of the Python backend picks from Sonnet 4.5, Opus 4.5 and Opus 4.6.

Amplifying's July edition on Fable 5 reads differently. Its Railway page lists 3 primary picks across 810 responses, and its report names Docker at 43 percent for the Python API repo.

My read is that an agent's pick belongs to the model that made it. Each new release can redraw it.

The claim reached most people through a thread by growth marketer Ira Bodnar, posted on X on October 14, 2026.

Bodnar's thread opens with the line that carried it: "Claude Code picks Railway for 82% of Python apps." He says you can ask the agent "how do I deploy this" and it installs Railway and puts your app live there. The rest of his thread lists the pages, guides and plugins he credits for Railway's growth. That part is his explanation of why the company grew. The benchmark behind the 82 percent measures what an agent recommends. It cannot show how many customers Railway won from it. Bodnar also admits one hole. Claude Code picks Vercel every time for Next.js and React apps, he writes.

The 82 percent comes from a study by Edwin Ong and Alex Vikati at Amplifying, published in February. They pointed Claude Code at real repos for 2,430 responses across three models, four repos and three runs each. No prompt named a tool. The Python result came from one FastAPI backend, where Railway took 82 percent of the picks. Docker had 8 percent, Fly.io 5 percent and Render 5 percent.

That is a narrow slice. Across all of the deployment answers, Amplifying's Railway page puts the February pick rate at 28.6 percent, which is 32 of 112 responses, with 26 more alternative picks. Vercel took 86.

Then Amplifying ran Fable 5

In July, Amplifying published a Fable edition. It says it reran the same prompts and repos on Fable 5, a total of 810 responses across four repos and 20 categories. The Railway page now carries a note at the top. In its words: "In the newest edition (810 responses, model claude-fable-5), Railway takes 3 primary picks, 21 alternative listings, and 10 mentions."

A primary pick is the tool the agent chose, an alternative listing is a tool it offered as another option, and a mention is a passing reference. The 3 primary picks are counted across the whole 810 response run. They do not sit on the same scale as an 82 percent share of Python picks. The report's table of Python API answers is the closer comparison, and there Amplifying lists Docker as the top deployment pick at 43 percent. It sums up the shift in one line: "Render (5) and Docker helped absorb the Python deploy work Railway used to own."

Amplifying's report also pitches private versions of this benchmark to developer tool teams. Disclosure: my agency, ViewEngine, sells AI visibility work and builds its own tracking tools.

Stripe has an open Head of AEO and SEO role that includes visibility in "coding assistants (e.g. Claude, Codex, etc.)" That listing is a real hiring decision by a large company.

So the channel exists, and the thread is right about that. What the thread leaves out is the date and the model. Bodnar presents 82 percent as a standing fact about Claude Code. Amplifying's own pages show a newer model producing a different Railway result, and I would not build a plan on the old figure.

The mistake here is treating a benchmark with a date on it as a property of the product. Visibility in an AI answer is probabilistic. The useful reading comes from many runs, and from the same runs repeated on every model version. A pick rate means something only with its model, its prompts, its sample and its collection date attached.

My guess is the next model release moves the Python lane again. Until someone shows me a pick rate that survives a model swap, I treat every one of these numbers as a snapshot with an expiry date.