Model Garden and choosing a model

Before the fifth session Farah sent Owen a link and one instruction: "Spend twenty minutes in Model Garden and come back with three models you would shortlist for the shopping assistant, and why." Owen came back with five, because he could not decide, and a page of questions. "That's the right reaction," Farah said. "There are hundreds of models in there. Nobody should pick one by reputation. You pick one by testing it on your own task."

This lesson covers Model Garden, the model catalog on the AI platform, the kinds of models it offers, and a practical way for a business to choose a model. The exam guide places Model Garden under the platform's developer tools and expects a leader to understand why choice matters and which factors drive it.

What Model Garden is

Model Garden is the catalog of models available on the Gemini Enterprise Agent Platform. It lists Google's own models, models from partner companies and open models, each with a model card describing what the model does, how it was evaluated, its limits and its license. From Model Garden, a team can try a model in a test console, call it through an API, tune it where tuning is supported, or deploy it to its own endpoint. Public descriptions of the catalog put it at more than 200 models; the number keeps changing, so treat it as "a lot" rather than a fixed figure.

Farah reminded Owen of the exam guide's phrase about Google Cloud's open approach: customers are not limited to Google's own models. A company can choose a partner model for a task where it performs best, or an open model it can run and inspect itself, while keeping the same security, billing and governance on the platform.

Model families and sizes

Even within one family, models come in sizes. Larger models are generally more capable at complex reasoning, long documents and difficult instructions; smaller models are faster and cheaper per request and are often good enough for simple, high-volume tasks such as classification, extraction and short answers. Google usually offers several Gemini variants at once, typically a highly capable model, a faster and cheaper one, and sometimes an even lighter one, and it releases new versions regularly. A leader does not need to memorize the current version numbers, which change every few months, but should understand the trade-off between capability, speed and cost.

The factors that decide a model choice

Farah gave Owen a list of factors, in the order she asks about them.

Two factors deserve extra attention. Data location matters because not every model is offered in every region, and some features process data in specific locations; Teresa's organization policy limited Birchline to approved US regions, which immediately ruled out a few options. Cost matters because generative AI is usually billed by the amount of text processed, so a small difference per request becomes a large difference at volume.

# Illustrative monthly cost comparison for three candidate models.
# Prices are invented for the example, per million tokens processed.
conversations_per_month = 40_000
turns_per_conversation = 4
input_tokens_per_turn = 3_000     # question + history + retrieved product details
output_tokens_per_turn = 350

candidates = {
    "Large model":  {"in": 1.25, "out": 10.00},
    "Mid model":    {"in": 0.30, "out": 2.50},
    "Small model":  {"in": 0.10, "out": 0.40},
}
turns = conversations_per_month * turns_per_conversation
for name, price in candidates.items():
    cost = turns * (input_tokens_per_turn * price["in"] + output_tokens_per_turn * price["out"]) / 1_000_000
    print(f"{name:12} about {cost:8.0f} a month")

Large model  about     1160 a month
Mid model    about      284 a month
Small model  about       70 a month

The invented prices show the shape of the problem rather than real figures. Input tokens dominate here because every turn includes the conversation history and retrieved product details. That suggests two cost levers that do not involve changing models at all: retrieving fewer, better product passages, and summarizing long conversations instead of resending every word.

A practical way to choose

Farah's method, which she called shortlist, test, decide, takes about two weeks for a project like the shopping assistant.

• Write the requirements down. Use the factor table above. Anything that is a hard limit, such as region, rules models out immediately.
• Shortlist two or three models. Usually one capable model, one faster and cheaper model, and perhaps one partner or open model if there is a reason.
• Build a test set. Collect real questions, here 200 drawn from customer service emails and store staff, with what a good answer looks like.
• Run the same prompt and grounding on each model. Change only the model, so the comparison is fair.
• Score the results. Use the platform's evaluation tools and a human review of a sample. Measure latency and estimated cost too.
• Decide and record why. Write down the choice and the evidence, so the decision can be revisited when new models appear.

Farah also suggested a common pattern: use different models for different steps. A small, fast model could classify each customer message (product question, order problem, complaint) and route it, while a more capable model handles the complicated product advice. Routing keeps quality high where it matters and cost low where it does not.

# Illustrative routing: a cheap model classifies, an expensive model only answers hard questions.
messages = [
    ("Where is my order 10482?", "order"),
    ("What sleeping bag rating for late September in the mountains?", "advice"),
    ("Do you have size 9 hiking boots at the downtown store?", "stock"),
    ("Compare these two tents for a family of four", "advice"),
    ("I want to complain about a late delivery", "complaint"),
]
route = {"order": "order system lookup", "stock": "inventory lookup",
         "advice": "capable model with product grounding", "complaint": "human agent"}
for text, kind in messages:
    print(f"{kind:9} -> {route[kind]:38} | {text}")
hard = sum(1 for _, k in messages if k == "advice")
print(f"Only {hard} of {len(messages)} messages need the expensive model")

order     -> order system lookup                    | Where is my order 10482?
advice    -> capable model with product grounding   | What sleeping bag rating for late September in the mountains?
stock     -> inventory lookup                       | Do you have size 9 hiking boots at the downtown store?
advice    -> capable model with product grounding   | Compare these two tents for a family of four
complaint -> human agent                            | I want to complain about a late delivery
Only 2 of 5 messages need the expensive model

Open models: when they make sense

Owen's shortlist included Gemma, and he asked when a company should choose an open model. Open models are released with their weights, the learned numbers that make up the model, so a company can run them on infrastructure it controls, inspect them, and adapt them freely within the license. Reasons to choose one include strict requirements to run inside the company's own environment, a need to modify the model deeply, very high volumes where running a small model on dedicated hardware is cheaper, or a desire to avoid dependence on one provider. The trade-off is responsibility: the company, not Google, then manages hosting, scaling, updates and some safety controls. For Birchline's first project, a managed model was the sensible choice.

Model cards and responsible choice

Every model in Model Garden comes with a model card, a short document describing intended uses, known limitations, how the model was evaluated and the license terms. GCP-110 explained why responsible AI starts with understanding a model's limits. Reading the card is the quickest way to spot a mismatch, such as a model that was not evaluated on the languages a company needs, or a license that forbids a planned use. Birchline's shop serves customers in English and Spanish, so language support was on Owen's checklist.

Models change, so plan for change

Model providers release new versions regularly, and older versions are eventually retired. A choice that is right in November 2026 may not be right a year later, either because a better or cheaper model appears or because the chosen version reaches the end of its support. Farah built three habits into Birchline's plan. First, the application refers to the model through a single setting rather than in many places in the code, so switching is a small change. Second, the test set and evaluation scores from the original choice are kept, so any new model can be compared on exactly the same questions. Third, someone on the team watches Google's release notes and model lifecycle pages and reviews the choice at least twice a year.

Owen asked whether a newer model is always better. Usually it is better on average, Farah said, but not necessarily on every task, and its answers may differ in style, length or format in ways that break an application that expects a particular shape of output. That is why a model upgrade is treated as a change to test, not an automatic improvement.

Owen's final shortlist for the shopping assistant had two Gemini variants and nothing else. "A partner model might be better at something," he said, "but we don't have a reason to think so yet. If the test shows a gap, we'll add one." Farah wrote "good answer" on his notes.