Every new model release triggers the same tired debate. Commentators rush to crown a winner and declare the previous tier dead. With GPT-5.6 Luna sitting alongside Terra and Sol, the narrative writes itself: Luna is cheap enough and capable enough to make Terra irrelevant. This is wrong. It is also expensive. Picking a model for your coding agents is not a beauty contest, a team identity, or a benchmark horse race. It is an operating policy. The teams that internalize this distinction will spend less, move faster, and break fewer things than the teams that default to the strongest model for every request.

Your Default Should Be the Cheapest Tool That Fits

Luna is the value tier, and that is not faint praise. It thrives on bounded, explicit, and easy tasks. Think classification, summarization, short code edits, and first-pass research. When an agent parses a support ticket to assign a priority label, Luna is enough. When it renames a variable across a few files or drafts a one-paragraph summary of a git diff, Luna is enough. These are jobs with narrow scopes, clear inputs, and objectively checkable outputs.

The economic effect is what changes the game. Luna is cheap. At high volume, this shifts automation from an expensive ceremony to infrastructure. You stop counting tokens and start measuring throughput. A cheap model that clears eighty percent of routine tasks is more valuable than an expensive model that clears eighty-five percent if that extra five percent does not change the outcome. If Luna generates a unit test in two seconds and Terra generates a marginally cleaner one in eight seconds for five times the cost, the math only works if someone is carefully auditing every line. Most of the time, no one is. Luna should be your default for bounded work precisely because most work is bounded.

Escalate When the Boundaries Disappear

Terra is not useless. It is your escalation tier, and it earns its keep on tasks without clear boundaries. Use it when the goal is underspecified or when the work involves complex systems like deployment paths, cross-module changes, or incident triage. A deployment path that snakes through staging, canary, and production environments with feature flags does not have a tidy spec sheet. A refactor that touches the billing logic and quietly ripples into the reporting pipeline is not a bounded task. A production incident where the logs scream about API timeouts but the root cause lives in a migration script from last quarter requires judgment.

Terra provides that judgment. It separates symptoms from causes. Luna might patch a retry loop to stop the bleeding. Terra asks whether the retry loop should exist at all, or whether the underlying timeout architecture is the real problem. That difference matters when the wrong fix turns a temporary slowdown into a cascading failure. A stronger model that prevents one bad production migration is worth the price if it saves an engineer a full day of cleanup. One prevented outage pays for months of escalation margin.

Sol Is the Insurance Policy, Not the Daily Driver

Sol exists for cases where extra capability justifies the high cost. Use it for high-risk reviews or architectural changes. Rebuilding the authentication flow, redesigning database sharding, or approving a pull request that touches the payment gateway are not daily occurrences. They are events. Sol should not be your default. It should be your exception handler, summoned when the cost of failure is too high for cheaper models to carry alone.

For the highest-risk category, pair Sol with a deterministic verifier. Let Sol suggest the schema change or reason through the architectural trade-offs. Let your CI pipeline, static analysis, and integration tests confirm the mechanical details. The model brings intuition. The verifier brings guarantees. That combination is what protects you when the blast radius is largest.

Build a Router, Not a Religion

The real metric is not which model is best. The question is which model should handle this task based on cost, latency, and blast radius. Stop treating model choice as an identity. Do not say, "We are a Terra shop." Instead, route by task class.

ಒಂದು ಸರಳ ವರ್ಗೀಕರಣಕಾರಿಯನ್ನು (classifier) ನಿರ್ಮಿಸಿ. ಬರುವ ಕಾರ್ಯಗಳನ್ನು ಅವುಗಳ ಪರಿಣಾಮದ ವ್ಯಾಪ್ತಿಯ (blast radius) ಆಧಾರದ ಮೇಲೆ ಟ್ಯಾಗ್ ಮಾಡಲಾಗುತ್ತದೆ. ಕಡಿಮೆ ಪರಿಣಾಮದ ವ್ಯಾಪ್ತಿಯ ಕೆಲಸಗಳು Luna ಗೆ ಹೋಗುತ್ತವೆ. ಮಧ್ಯಮ ಪರಿಣಾಮದ ವ್ಯಾಪ್ತಿಯ ಕೆಲಸಗಳು Terra ಗೆ ಹೋಗುತ್ತವೆ. ಹೆಚ್ಚಿನ ಪರಿಣಾಮದ ವ್ಯಾಪ್ತಿಯ ಕೆಲಸಗಳು ಒಂದು ಬಲವಾದ ಮಾಡೆಲ್ ಮತ್ತು ನಿರ್ಣಾಯಕ ಪರಿಶೀಲಕಕ್ಕೆ (deterministic verifier) ಹೋಗುತ್ತವೆ. ಪ್ರಾರಂಭಿಸಲು ನಿಮಗೆ ಪರಿಪೂರ್ಣವಾದ ಮಷೀನ್ ಲರ್ನಿಂಗ್ ವರ್ಗೀಕರಣಕಾರಿಯ ಅಗತ್ಯವಿಲ್ಲ. ಕೆಲವು ನಿಯಮಗಳು (heuristics) ಸಾಕಾಗುತ್ತವೆ. ಕೇವಲ ಆಂತರಿಕ ಉಪಯುಕ್ತತೆಗಳನ್ನು (internal utilities) ಮಾತ್ರ ಸ್ಪರ್ಶಿಸುವ ಮತ್ತು ಕಡಿಮೆ ಸಾಲುಗಳಿರುವ ಕೋಡ್ ವಿಮರ್ಶೆಗಳು? Luna. ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ಪೈಪ್‌ಲೈನ್‌ಗಳು, ಕ್ರಾಸ್-ಸರ್ವಿಸ್ ಕರೆಗಳು ಅಥವಾ ಅಸ್ಪಷ್ಟ ಅಗತ್ಯತೆಗಳನ್ನು ಉಲ್ಲೇಖಿಸುವ ಟಿಕೆಟ್‌ಗಳು? Terra. ಗ್ರಾಹಕರ ಡೇಟಾ, ನಿರ್ಣಾಯಕ ಹಾದಿಗಳು (critical paths) ಅಥವಾ ಕಾನೂನು ಅನುಸರಣೆಯನ್ನು (legal compliance) ಸ್ಪರ್ಶಿಸುವ ಯಾವುದೇ ವಿಷಯ? Sol ಗೆ ವರ್ಗಾಯಿಸಿ ಮತ್ತು ಮಾನವ ಅಥವಾ ನಿರ್ಣಾಯಕ ವಿಮರ್ಶೆಯನ್ನು ಬಯಸಿ.

ಫಲಿತಾಂಶಗಳನ್ನು ಅಳೆಯಿರಿ, ಮಾಡೆಲ್ ಹೆಸರುಗಳನ್ನಲ್ಲ. ಪ್ರತಿ ಕಾರ್ಯದ ವೆಚ್ಚ, ಮರುಪ್ರಯತ್ನದ ದರ (retry rate) ಮತ್ತು ತಪ್ಪಿಹೋದ ದೋಷಗಳನ್ನು (escape defects) ಪತ್ತೆಹಚ್ಚಿ. ನೀವು Luna ಗೆ ನಿಯೋಜಿಸಿದ ಕಾರ್ಯಗಳಲ್ಲಿ ಅದು ವಿಫಲವಾಗುತ್ತಿದ್ದರೆ, ಅದರ ವ್ಯಾಪ್ತಿಯನ್ನು ಹೆಚ್ಚಿಸಿ. ಪ್ರತಿದಿನ ಪುನರಾವರ್ತನೆಯಾಗುವ ಮಾದರಿಗೆ Terra ಅತಿಯಾದ ಶಕ್ತಿಯಾಗಿದ್ದರೆ, ಅದನ್ನು Luna ಗೆ ಇಳಿಸಿ ಮತ್ತು ನಿಮ್ಮ ವೆಚ್ಚವು ಹೇಗೆ ಕಡಿಮೆಯಾಗುತ್ತದೆ ಎಂದು ಗಮನಿಸಿ. ಗುರಿಯೆಂದರೆ ನಿಮ್ಮ ಬಜೆಟ್ ಮೀರಿ ಹೋಗದಂತೆ ಆಟೊಮೇಷನ್ ಅನ್ನು ಹೆಚ್ಚಿಸುವುದು. Luna ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಹಿನ್ನೆಲೆ ಕೆಲಸಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. Terra ನಿರ್ಧಾರಗಳು ಮುಖ್ಯವಾಗುವ ಸಂದರ್ಭಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. Sol ನಿಮ್ಮ ವಾರವನ್ನೇ ಹಾಳುಮಾಡಬಹುದಾದ ಅಪವಾದಗಳಿಗಾಗಿ ಕಾವಲು ಕಾಯುತ್ತದೆ.

ಇದನ್ನು ಸರಿಯಾಗಿ ಮಾಡುವ ತಂಡಗಳು ತಮ್ಮ ಏಜೆಂಟ್ ಫ್ಲೀಟ್ ಅನ್ನು ಉತ್ತಮವಾಗಿ ನಡೆಸಲ್ಪಡುವ ಇಂಜಿನಿಯರಿಂಗ್ ಸಂಸ್ಥೆಯಂತೆ ಪರಿಗಣಿಸುತ್ತವೆ. ಅವರು ಪ್ರತಿಯೊಂದು ಪ್ರಾಜೆಕ್ಟ್‌ಗೆ ಆರ್ಕಿಟೆಕ್ಟ್‌ಗಳನ್ನು ನೇಮಿಸುವುದಿಲ್ಲ ಮತ್ತು ಇಂಟರ್ನ್‌ಗಳನ್ನು ಕೋರ್ ಡೇಟಾ ಮಾಡೆಲ್ ಅನ್ನು ಮರು ವಿನ್ಯಾಸಗೊಳಿಸಲು ಕೇಳುವುದಿಲ್ಲ. ಅವರು ಸಾಮರ್ಥ್ಯವನ್ನು ಅಪಾಯಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಹೊಂದಿಸುತ್ತಾರೆ. ನಿಮ್ಮ ಮಾಡೆಲ್‌ಗಳೊಂದಿಗೆ ಕೂಡ ಇದನ್ನೇ ಮಾಡಿ.

ಮೂಲ ಚರ್ಚೆಯನ್ನು ಓದಿ: GPT-5.6 Luna Is The Value Tier. Terra Is Not Useless

GyaanSetu ಕಲಿಕಾ ಸಮುದಾಯವನ್ನು ಸೇರಿ: t.me/GyaanSetuAi