<p>This is a small release with an interesting story about mapping mismatches.</p><h2>The new dial</h2><p>When Opus 4.8 shipped, it came with a wider thinking range than its predecessor. Where Opus 4.7 topped out at <code>xhigh</code>, Opus 4.8 added two more levels above it:</p><pre><code>Faster                                                 Smarter
──────────────────────────────▲────────────┆──────────────────
low     medium     high     xhigh      max       ultracode
</code></pre><p><code>ultracode</code> is the new ceiling. The most reasoning Opus 4.8 will do. Maximum judgment, maximum independence, maximum time spent thinking before acting.</p><p>The problem: Elyra's thinking control only has five settings.</p><h2>The mismatch</h2><p>Elyra exposes thinking as five levels: <code>minimal</code>, <code>low</code>, <code>medium</code>, <code>high</code>, <code>xhigh</code>. That worked fine when Anthropic's models had a matching range. But Opus 4.8 has six effort levels:</p><pre><code>Elyra:      minimal   low    medium   high   xhigh
Opus 4.8:   low    medium    high    xhigh    max    ultracode
</code></pre><p>Five knob positions, six destinations. Something has to give.</p><p>Our first instinct was to map the top of Elyra's scale to the top of Opus's scale and leave the rest alone:</p><pre><code>high  → max
xhigh → ultracode
</code></pre><p>But then we looked closer at our own defaults and noticed something. Elyra's <code>minimal</code> and <code>low</code> both mapped to the same Opus effort (<code>low</code>). Two distinct knob positions doing the exact same thing. Wasted slots.</p><p>As the maintainer put it: <em>"we have minimal and low, we don't need both."</em></p><h2>The fix</h2><p>If <code>minimal</code> and <code>low</code> are redundant at the bottom, we can collapse them and spread the rest across the full range. That frees up enough positions to reach every meaningful Opus 4.8 effort:</p><pre><code>minimal → low
low     → medium
medium  → high
high    → max
xhigh   → ultracode
</code></pre><p>Now every Elyra thinking level maps to a distinct Opus 4.8 effort. Crank the dial to <code>xhigh</code> and you get <code>ultracode</code> — the smartest setting Anthropic offers. Dial it down and you get progressively faster, cheaper responses.</p><p>In practice:</p><pre><code>/settings → Thinking level → xhigh
</code></pre><p>Or set it for a single hard problem:</p><pre><code>&gt; Refactor the entire auth system to use passkeys. Take your time.
</code></pre><p>With thinking at <code>xhigh</code>, Opus 4.8 runs at <code>ultracode</code> — it'll reason longer, plan more carefully, and work more independently before producing the change.</p><p>For a quick lookup, dial it down:</p><pre><code>/settings → Thinking level → minimal
</code></pre><p>That maps to <code>low</code> effort — fast, cheap, good enough for "what's the syntax for a PHP match expression again?"</p><h2>The part where the SDK lagged</h2><p>Here's a recurring theme in these model-day releases: the official SDK types are always a step behind the actual API.</p><p>When we went to add <code>ultracode</code>, the Anthropic SDK's type for effort levels was:</p><pre><code class="language-typescript">effort?: 'low' | 'medium' | 'high' | 'xhigh' | 'max' | null;
</code></pre><p>No <code>ultracode</code>. Just like a few days ago, when <code>xhigh</code> wasn't in the types either. The API supports it, the announcement mentions it, but the published TypeScript definitions haven't caught up.</p><p>We'd already solved this once with a targeted type cast for <code>xhigh</code>. This time we generalized it so it handles any effort value the SDK doesn't yet know about:</p><pre><code class="language-typescript">const sdkKnownEfforts = new Set(["low", "medium", "high", "max"]);
params.output_config = sdkKnownEfforts.has(options.effort)
    ? { effort: options.effort as "low" | "medium" | "high" }
    : ({ effort: options.effort } as unknown as NonNullable&lt;
          MessageCreateParamsStreaming["output_config"]
      &gt;);
</code></pre><p>If the SDK knows the effort value, we pass it through with proper typing. If it doesn't — <code>xhigh</code>, <code>ultracode</code>, or whatever comes next — we cast around the stale types. When the SDK catches up, the cast becomes a harmless no-op. No more one-off patches for each new effort level.</p><h2>Why we ship these so fast</h2><p>This is the fourth release in three days that touches Opus 4.8. Add the model. Fix the thinking mode. Add the effort level. Refine the mapping.</p><p>That cadence isn't chaos — it's the point. When a frontier model ships, the details emerge over days: which effort levels exist, how thinking is configured, what the SDK supports. A monolithic agent locked to quarterly releases would make you wait. Elyra ships the moment we learn something new.</p><p>Each of these was a few lines of code, a passing <code>npm run check</code>, and a publish. The infrastructure is built so that following a fast-moving model is a small, repeatable operation rather than a project.</p><h2>Get it</h2><pre><code class="language-bash">npm install -g @elyracode/coding-agent@0.8.4
</code></pre><p>Set your thinking level to <code>xhigh</code> and you're running Opus 4.8 at <code>ultracode</code>. Or leave it at the default and let adaptive thinking decide.</p><p>Full changelog: <a target="_blank" rel="noopener noreferrer nofollow" href="https://elyracode.com/changelog">v0.8.4</a></p>