I think for the majority of the audience here who use these models inside of coding agent harnesses w/ subsidized monthly subscriptions, there likely isn't one. Depending on how Terra contributes to the rate limits, it may make sense to use it for some subset of a repeated workflow to get more mileage out of sub.
If you pay API prices for inference in your product stack & have specific use-cases w/ custom evals, these smaller models provide an additional cost/speed lever to adjust. Ultimately, I think the point is to compete on cost for use-cases where Sol on the lowest reasoning is overkill.
If you have a fairly straightforward usecase where Terra performs just as well as Sol, but is faster and cheaper, why not use it?
The real issue with coding harnesses is that you get a cache miss any time you switch models. I might have some easy task (e.g. "fix lints") that I could delegate to Terra, because my session has been using Sol up to this point, I'd pay a full uncached prefill if I routed it to Terra. It ends up being cheaper in practice to just stick with Sol.
Spinning up a fresh session would be a reasonable choice in the above case, but sometimes you still need the retained context.
Yes but you are missing the point. It's the case where Luna is not good enough, and Sol is too much. The problem is that on benchmarks Luna xhigh is typically comparable to Sol low in terms of capability. So where does Terra fit in?
World knowledge, factual recall without grounding, more complex instruction following, etc.
Benchmarks don’t really tell you much. For API best will always be a model+effort sweep on your internal evals (and if you don’t have internal evals, do that first).
For individual coding harnesses, honestly I just go with vibes. The best workflow is the one that works for you.