Most coding tasks don’t need a frontier model, but which ones do?

Coding agents are one of the fastest-growing costs in engineering, and most teams run frontier models on every task by default. Open models can handle much of that work for far less, but generic benchmarks won’t tell you which ones fit your codebase.

This guide gives engineering leaders a step-by-step framework, drawn from how Baseten customers adopt open models, for finding the right model for each task and proving it with your own data.

Common questions

Who is this guide for?
Engineering leaders, platform teams, and anyone who owns AI coding spend and needs to bring costs down without slowing engineers down or lowering code quality.

What will I learn?
How to set a quality bar using the closed model your team trusts today, shortlist open models that can match it, benchmark them against about 30 of your own merged PRs, and scope a pilot that gives you real evidence on quality, cost, and speed.

Do my engineers have to switch tools?
No. The guide recommends keeping your existing harness, whether that’s Claude Code, Codex, Cursor, OpenCode, or something internal. The model is the only thing that changes, which makes results easier to measure and adoption easier to win.

What’s the most important metric to track?
Cache-adjusted cost per successful task. Cost per token hides the retries and extra reasoning some models need. The guide explains what drives the real number and how to measure it.

Does this mean replacing closed models entirely?
No. Most teams end up with a mixed fleet: frontier closed models on the hardest, longest-running work, and open models on high-volume tasks like migrations, refactors, and bug fixes.