About

I’m Jon Schenker, a software architect. I’ve shipped projects in Swift, Java, .NET, Angular, React and Flutter — mobile, web and backend — and that’s probably why I never grew attached to any one language. A language is a tool, and a good tool is the one that solves the problem in front of you today. What survives a change of stack is the architecture: how the pieces talk to each other, where the system will hurt as it grows, what can wait and what can’t.

What actually drives me is the stuff that isn’t finished yet. New technology, a tool released last week, an idea nobody has properly tested — that’s where I want to be, hands on it before there’s a consensus about it. A good part of what’s published here started exactly that way: curiosity about something that had just come out.

For the last three years that curiosity has had a fixed address: AI. I test models running locally, compare them against what the paid API delivers, and use coding agents on real work — vibe coding, as people call it — to find out where they help and where they get in the way. That’s the difference between having an opinion about a tool and having a measurement of it.

I’m also a gamer, and that has more to do with this site than it seems: the same card that runs games runs language models. That’s roughly how this started. Instead of leaving the GPU idle between matches, I started loading models onto it and measuring what came out. Curiosity turned into method, and method turned into work.

This site is the public record of that work.

What you’ll find here

Posts about running local LLMs: how much VRAM each configuration actually consumes, how many tokens per second each model produces at each quantization, when it’s worth trading an API for your own GPU and when it isn’t. The tooling around it — Ollama, llama.cpp, Aider, LiteLLM, coding agents — tested in real use, not in a demo.

Model comparisons and coverage of new releases are in scope too, and often: the field moves too fast to ignore what shipped this week. There’s one rule — I run it before I write about it. News here comes with a test attached, not with a press release.

What you won’t find: an announcement passed along without me having run it, predictions about the future of AI, tutorials copied from official docs.

Three rules I follow

Every number ships with its provenance. Hardware, runtime version, measurement method and number of runs. A throughput figure without those four things isn’t a measurement, it’s a claim — and a claim helps nobody decide anything.

If it can’t be reproduced, I don’t publish it. Full command, pinned version, explicit parameters. If you have the same card, you should land on the same number. If you don’t, you should be able to adjust the math.

Failure is a result too. When a model disappoints, the post says so. When I misconfigured something and lost two hours, the post tells that story — because it’s exactly the part nobody writes and everybody needs.

About the translations

I write in Portuguese. The English and Spanish versions are translated by a model running on my own bench, through the gateway these posts describe, and reviewed by me before publishing.

That’s deliberate: a site about running AI locally that outsourced its own translation would be a contradiction. When a post appears translated, it names the model that did the work.

What I do besides writing here

I help people and companies get AI working inside their business — not as a demo, but as a system in production. In practice: picking the right model for the problem (and sometimes concluding no model is needed at all), deciding what runs locally and what goes to an API, building the infrastructure around it — queues, cache, observability, cost control — and leaving the team able to operate it without depending on me.

The same rigour as the posts applies here: before proposing an architecture, I measure. A proposal that starts with “AI will solve it” tends to end up expensive.

I do this work through Nexttag. If you’re evaluating AI in your product or your operation and want a technical conversation before any commercial proposal, just write.

Contact

If a number here doesn’t match your measurement, I want to hear about it — corrections are what make this site worth anything.

Serious matters go by email, through the company address: contato@nexttag.com.br. Write with the concrete problem — what you tried, on what hardware, where it broke — and I’ll answer. Generic outreach and “unmissable opportunities” I don’t answer.