# Moving Half of Our AI Development to Local LLMs — by Splitting Work by Role, Not by Picking the Biggest Model

> Source: <https://dev.to/uehara/moving-half-of-our-ai-development-to-local-llms-by-splitting-work-by-role-not-by-picking-the-cnb>
> Published: 2026-08-10 23:03:25+00:00

Uehara, EarthLink Network Co., Ltd. I build and run more than 20 products by myself, with Claude Code at the core of development. This is a field note from that work.

On July 30, 2026, on the control panel that runs our in-house AI development, the share of work handled by local LLMs reached 50.3%, with the cloud side at 48.2%. This does not mean our bill was cut in half. It means the split of execution volume — including transcripts — came out to roughly fifty-fifty.

[画像: Share of work between local LLMs and the cloud. Absolute usage and account details have been redacted.]（画像は別途ホスティング予定）

How I thought about this changed a great deal from where I started.

At the beginning my idea was simple: load a single 70B-class model onto the large memory of a DGX Spark, and it would make a good commander. Bigger must be smarter — a naive assumption.

When I actually measured, the result was the reverse.

For the task of classifying work, I compared 14B, 32B, and 72B across 16 cases. The final classification agreement was the same for 14B and 72B; the 72B was simply five times slower. For code generation, the test pass rate was the same, and the 72B was six times slower. On top of that, most failures were not about how smart the model was, but about whether the generated diff could be applied at all.

"Bigger models are better" did not hold — at least not for this use.

Trying to co-host the 14B and the 72B on the same machine, I got the memory math wrong. On paper the model weights fit, but once you include context they physically do not. Classification stalled for four and a half minutes. After I shortened the classifier's context, both could stay resident and the stall dropped to about twelve seconds. Estimating without measuring turned straight into failure.

[画像: A design mock of routing and efficiency. All numbers in the image are dummy values.]（画像は別途ホスティング予定）

So I changed my approach. Instead of building a ranking of models, I split tasks by role. Light judgments go to a small local model; heavy work goes to the cloud. And dangerous operations — database, authentication, billing, production — always return to human approval, no matter what the model says. Code written by a local model gets no lighter a review.

That is where the 50.3% at the top comes from. It is not a story about local LLMs replacing the cloud. It is a record of splitting work by role, measuring it, and building something you can roll back when it fails — and of how that helped not only cost but also speed and safety.

What I will measure next is not the token ratio, but the total cost and time per successful task.

Uehara builds AI at EarthLink Network Co., Ltd. Since 2025 I have put Claude Code at the center of development, and I now build and run more than 20 products by myself. In this series I write about what actually happens on the ground — the wins and the failures alike — together with the numbers.
