Designing So the Next Shutdown Notice Doesn't Cost You an Afternoon: Isolating Gemini Behind a Single Port

Hold "what it can do right now" declaratively

When a model changes, it isn't only price and latency that shift — what it can do changes too. Input token limits, JSON mode support, image input. Scatter these as implicit assumptions and every swap breeds invisible bugs.

So hold capabilities() declaratively, and let the app check before it calls.

// app side — check capabilities before calling
function buildPrompt(gen: TextGenerator, docTokens: number): GenerateInput {
  const caps = gen.capabilities();
  if (docTokens > caps.maxInputTokens) {
    // route inputs over the limit through a summarize-first path
    return { prompt: summarizeFirst(docTokens), json: caps.jsonMode };
  }
  return { prompt: fullDocument(), json: caps.jsonMode };
}

With this small step, even if you degrade to a model with a smaller limit, the app logic doesn't break. Holding capabilities as a runtime-checkable value is what gives exit-ability its substance.

Don't stop when something falls over — fallback

The benefit of the port isn't only the swap. You can write, in the same shape, a structure that lines up multiple implementations and tries them in order. It becomes insurance when a preview model is unstable or you hit a rate limit.

// fallback.ts — try implementations that satisfy the same port, in order
import type { TextGenerator, GenerateInput, GenerateResult } from "./port";
 
export class FallbackTextGenerator implements TextGenerator {
  readonly id = "fallback-chain";
 
  constructor(private chain: TextGenerator[]) {
    if (chain.length === 0) throw new Error("chain must not be empty");
  }
 
  capabilities() {
    // fold to the most restrictive capability — that is the safe floor
    return this.chain.reduce((acc, g) => {
      const c = g.capabilities();
      return {
        streaming: acc.streaming && c.streaming,
        jsonMode: acc.jsonMode && c.jsonMode,
        maxInputTokens: Math.min(acc.maxInputTokens, c.maxInputTokens),
        imageInput: acc.imageInput && c.imageInput,
      };
    }, this.chain[0].capabilities());
  }
 
  async generate(input: GenerateInput): Promise<GenerateResult> {
    let lastErr: unknown;
    for (const g of this.chain) {
      try {
        return await g.generate(input);
      } catch (e) {
        lastErr = e; // move quietly to the next implementation
      }
    }
    throw new AggregateError([lastErr], "all providers failed");
  }
}

Here is a production gotcha. If you return the fallback's capabilities as "whatever the first implementation reports," things break only after degrading when the second model doesn't support JSON mode. As in the code above, folding to the most restrictive capability across the chain is the safe choice. I once hit a bug where JSON parsing failed only during fallback, and it cost me real time to isolate.

Watch deadlines in CI — the deadline guard

The last piece of exit-ability is not relying on human memory for deadlines. Reading the changelog every day isn't realistic. Collect the features you depend on and their shutdown dates into one table, and watch them in CI.

# deprecations.py — gather dependency shutdown dates in one place
from datetime import date
 
DEADLINES = {
    "image-generation-preview": date(2026, 8, 17),
    "gemini-cli-personal": date(2026, 6, 18),
}
 
def days_left(feature: str, today: date | None = None) -> int:
    today = today or date.today()
    return (DEADLINES[feature] - today).days

Then turn the build red once the remaining window drops below a threshold.

# test_deadlines.py — fail CI at 90 days out to force a migration ticket
import pytest
from datetime import date
from deprecations import days_left, DEADLINES
 
WARN_WINDOW = 90  # go red below this many days
 
@pytest.mark.parametrize("feature", list(DEADLINES))
def test_deadline_not_imminent(feature: str) -> None:
    left = days_left(feature, date.today())
    assert left > WARN_WINDOW, (
        f"{feature} shuts down in {left} days. File a migration ticket."
    )

By the time this test goes red, you still have months of runway. You structurally avoid the situation of scrambling late at night. I strongly recommend committing your deadline discipline to code. Entrusting the decision to a test rather than to memory lasts far longer in solo development.

What goes in the layer, and what doesn't

Chase exit-ability too hard and you freeze up instead. The line I arrived at in real operation is this.

What belongs in the layer is any capability that has multiple call sites and whose provider might change. Text generation, embeddings, image generation, speech synthesis — each is worth isolating. Models churn hardest here, so the cost of scatter is greatest.

This line was tested again by a recent update. When gemini-embedding-2 went GA and File Search began handling images and text together, the first thing I did was confine the embedding calls behind a port of the same shape. Generation and embedding run on different implementations, but the contract — hand over an input, receive a vector — does not change. When a new capability arrives is exactly when to confine it before you spread it. Make that a habit, and the next time an embedding model changes, the impact stays inside the adapter.

Some things are better left out of the layer. A feature that only makes sense on Gemini — a specific tool definition, or a model-specific setting — I don't force into an abstraction. The purpose of abstraction is to make swaps easy, not to erase every difference. In that case, writing it plainly inside the adapter reads better.

I, too, first tried to cram everything into the port and ended up building a sea of thin wrappers. After that lesson, I started judging the line by "number of call sites times the probability the provider changes."

An exit-ability checklist

When I start using a new Gemini capability, I check these four points.

1. Is the call confined to one place in the app? If it is going to scatter, cut a port first.
2. Do I hold the capabilities I use (limits, JSON, image input) in a runtime-checkable form?
3. If the feature has a shutdown date, did I register it in the DEADLINES table?
4. When the provider goes down, how does the app behave? Stop, or degrade? Have I decided?

If you can answer all four, then when the next end-of-service notice lands, you can state the blast radius instantly. What I lacked that morning was exactly the answer to the fourth.

Weaving exit-ability into a design isn't flashy work. But not melting an afternoon over a single notice changes, quite a lot, the stamina it takes to keep going as a solo developer. Start by confining the generation path you call most into a single port. Thank you for reading.