# From GPU to TPU with Coding Agents: What Works, What Fails, and What It Costs? > Source: > Published: 2026-11-02 20:33:21+00:00 # Computer Science > Software Engineering [Submitted on 25 Oct 2026 ( [v1](https://arxiv.org/abs/2610.34422v1)), last revised 29 Oct 2026 (this version, v2)] # Title:From GPU to TPU with Coding Agents: What Works, What Fails, and What It Costs? [View PDF](https://arxiv.org/pdf/2610.34422) [HTML (experimental)](https://arxiv.org/html/2610.34422v2) Abstract:A coding agent can migrate a machine learning workload, report success, and still change how the model trains. Rising compute costs, limited accelerator capacity, and vendor dependence are pushing organizations toward alternatives to graphics processing units (GPUs); a key question is whether agent-generated migrations to tensor processing units (TPUs) can be trusted and at what cost. We build a dataset of 148 PyTorch ML research projects and use Claude Code to migrate ten of them from NVIDIA GPUs to Google Cloud TPUs. We independently assess whether each migration runs, preserves numerical behavior, executes on the intended hardware, maintains the project's goal, and delivers acceptable performance. We also examine failures, human effort, and costs. Eight projects meet our project-goal criterion, and migrations require 2.4 human interventions on average. Of 70 execution attempts, 53 fail (76%), and 26 of these failures (49%) raise no error. The most frequent cause is repeated compilation and other execution inefficiencies, while interactions with third-party libraries can silently change the computation: in one four-chip migration, the agent reports success despite a change in gradient clipping that reduces accuracy from 86.53% to 84.89%. Execution costs vary widely: in one workload, TorchTPU, a PyTorch execution backend for TPUs, trains 1.86 times faster and 25% cheaper per run than the GPU. For practitioners, these findings motivate independent reference runs, verification under the intended hardware configuration, and workload-specific acceptance and stopping criteria that account for both computational and human costs. ## Submission history From: Hui Sun [ [view email](https://arxiv.org/show-email/f5f1c053/2610.34422)] **Sun, 25 Oct 2026 16:21:56 UTC (261 KB)** [\[v1\]](https://arxiv.org/abs/2610.34422v1) **[v2]** Thu, 29 Oct 2026 18:31:39 UTC (148 KB) ### Additional Features ### Current browse context: cs.SE ### References & Citations Loading... # Bibliographic and Citation Tools Bibliographic Explorer *(*[What is the Explorer?](https://info.arxiv.org/labs/showcase.html#arxiv-bibliographic-explorer)) Connected Papers *(*[What is Connected Papers?](https://www.connectedpapers.com/about)) Litmaps *(*[What is Litmaps?](https://www.litmaps.co/)) scite Smart Citations *(*[What are Smart Citations?](https://www.scite.ai/)) # Code, Data and Media Associated with this Article alphaXiv *(*[What is alphaXiv?](https://alphaxiv.org/)) CatalyzeX Code Finder for Papers *(*[What is CatalyzeX?](https://www.catalyzex.com)) DagsHub *(*[What is DagsHub?](https://dagshub.com/)) Gotit.pub *(*[What is GotitPub?](http://gotit.pub/faq)) Hugging Face *(*[What is Huggingface?](https://huggingface.co/huggingface)) ScienceCast *(*[What is ScienceCast?](https://sciencecast.org/welcome)) # Demos # Recommenders and Search Tools Influence Flower *(*[What are Influence Flowers?](https://influencemap.cmlab.dev/)) CORE Recommender *(*[What is CORE?](https://core.ac.uk/services/recommender)) # arXivLabs: experimental projects with community collaborators arXivLabs is a framework that allows collaborators to develop and share new arXiv features directly on our website. Both individuals and organizations that work with arXivLabs have embraced and accepted our values of openness, community, excellence, and user data privacy. arXiv is committed to these values and only works with partners that adhere to them. Have an idea for a project that will add value for arXiv's community? [**Learn more about arXivLabs**](https://info.arxiv.org/labs/index.html).