Why we built TheTensorTune

6 min readBlog post
Why we built TheTensorTune

The story behind TheTensorTune: what bothered us about existing fine-tuning tools, why the whole thing had to fit in one Python file, and what shipped in v1.0.

Every fine-tuning tutorial starts the same way: clone this repo, install these fourteen things, copy this yaml, fix the version conflict, edit three more files, and then — if nothing broke — you get a progress bar and no idea what it is doing to your data. We followed those tutorials more times than we can count. Somewhere around the fifth broken environment, the idea for TheTensorTune stopped being a joke.

The goal was never to compete with the big training frameworks. They are good at what they do. The goal was to take the standard loop — dataset, model, LoRA settings, training, evaluation, export — and make it something you can see and touch, start to finish, without leaving your browser tab. Fine-tuning is not a rare ritual anymore; for a lot of people it is a routine task, and it deserved a workbench instead of a checklist.

One file, on purpose

The constraint sounded silly when we wrote it down: the whole app is a single Python file. No package structure, no build step, no container image. The reason is practical. A single file is easy to read, easy to audit, easy to put on a USB stick and hand to a colleague. When someone asks “what does this actually do to my data?”, the answer can be “open the file and look”, and that answer actually fits in an afternoon of reading.

The constraint also kept us honest about scope. Every feature had to earn its place in the file. If something needed a microservice or a database server, it was out. What survived is the loop you see today: a canvas of wired blocks, a dataset quality check, training with live charts, a queue with checkpoints, test chat, before/after comparison, and GGUF export. Each one maps to a question a person actually has while fine-tuning.

What shipped in 1.0

  • The workbench — a node-graph canvas where every stage is a block, in English and full right-to-left Persian.
  • Training that is real — PEFT under the hood, with checkpoints, resume and early stopping.
  • Answers, not artifacts — test chat and a side-by-side comparison, because a model you cannot talk to is a file, not a result.
  • An export that runs — merge and quantize to GGUF in one click, ready for Ollama or llama.cpp.
  • A course inside the app — twelve lessons with screenshots, from first upload to API automation.

Before the 1.0 tag, the release went through fifty test scenarios — thirty functional, twenty end-to-end — plus a security regression suite covering path traversal, SSRF, XSS, CSRF, token handling and upload hardening. That part was not fun and we would not skip it. A tool that touches your files and runs a local server has to be boring in exactly the right places.

If you fine-tune models already, we think the workbench will feel like a shortcut you were missing. And if you have never done it, lesson one starts from zero and walks you through. Either way, tell us what breaks — the links are in the footer.

#behind the scenes#the loop