Skip to content

add gemma4 as a model for google - #225

Merged
handstandsam merged 1 commit into
block:mainfrom
mannydelgado:md/gemma-4-integration
Aug 7, 2026
Merged

add gemma4 as a model for google#225
handstandsam merged 1 commit into
block:mainfrom
mannydelgado:md/gemma-4-integration

Conversation

@mannydelgado

Copy link
Copy Markdown
Contributor

Integrate Gemma4 as a model for google provider.

This is limiting in terms of context size but it does allow for some free usage which is nice for testing.

Signed-off-by: Manny Delgado <manny@duolingo.com>
@mannydelgado
mannydelgado force-pushed the md/gemma-4-integration branch from 3d47191 to 6777b23 Compare August 4, 2026 02:11
@handstandsam
handstandsam merged commit a5e136e into block:main Aug 7, 2026
7 of 8 checks passed
handstandsam added a commit that referenced this pull request Aug 10, 2026
#225 added one Gemma 4 model to the google provider. Google serves three on the
Gemini API free tier (12B dense, 26B-A4B MoE, 31B dense) and Ollama publishes the
same three locally, so all six are now built in — pick one by id, no specs to
look up.

Two details worth calling out:

- `gemma-4-31b-it` and `gemma-4-26b-a4b-it` are both real, distinct models. The
  mismatch between #225's yaml and its LLM_MODELS.md row read like a typo; it
  wasn't, and regenerating the doc silently dropped one of them. Both are here now.
- max_output_tokens is 32768, not the 65536 the Gemini models use. Google
  publishes no output cap for Gemma 4; 32768 is the largest figure any host
  documents.

The e2b/e4b edge builds are deliberately omitted from Ollama — 128K context and
much weaker at the screenshot-driven tool calling Trailblaze's agent loop does.
Note `gemma4:latest` resolves to e4b, so name a size explicitly.

LLM_MODELS.md is generated from the provider yamls (`:docs:generator:run`).
handstandsam added a commit that referenced this pull request Aug 10, 2026
…a release (#229)

* Add every hosted Gemma 4 variant to the built-in model list

#225 added one Gemma 4 model to the google provider. Google serves three on the
Gemini API free tier (12B dense, 26B-A4B MoE, 31B dense) and Ollama publishes the
same three locally, so all six are now built in — pick one by id, no specs to
look up.

Two details worth calling out:

- `gemma-4-31b-it` and `gemma-4-26b-a4b-it` are both real, distinct models. The
  mismatch between #225's yaml and its LLM_MODELS.md row read like a typo; it
  wasn't, and regenerating the doc silently dropped one of them. Both are here now.
- max_output_tokens is 32768, not the 65536 the Gemini models use. Google
  publishes no output cap for Gemma 4; 32768 is the largest figure any host
  documents.

The e2b/e4b edge builds are deliberately omitted from Ollama — 128K context and
much weaker at the screenshot-driven tool calling Trailblaze's agent loop does.
Note `gemma4:latest` resolves to e4b, so name a size explicitly.

LLM_MODELS.md is generated from the provider yamls (`:docs:generator:run`).

* Document how to use a model Trailblaze doesn't ship with

Chasing model releases through Trailblaze releases is the wrong loop, and nothing
required it — a workspace trailblaze.yaml can declare any model its provider
serves, and it takes effect on the next run. That was documented only as a passing
sentence inside the LLM reference.

New 'Adding a Model' page covers it directly: how a workspace entry merges with the
built-in list (by id — new ids add, known ids override field-by-field), the 131K/8K
fallbacks you get by omitting the limits, recipes for hosted, local Ollama, and
gateway models, and how to contribute a model back to the built-in registry
(including regenerating LLM_MODELS.md, which is generated).

Also fills a real gap: the page titled 'Configuration' documented Android
instrumentation args and scripting timeouts and never mentioned trailblaze.yaml
itself. It now opens with the file — where it lives, that every section is
optional, what each top-level key does, the inline-or-ref shape, and one precedence
table — with the existing sections kept below.

* Point the External Config page at the trailblaze.yaml documentation

Landing on the generated External Config page gave no way to find out what
trailblaze.yaml itself is — the page covers the trails/config/ directory
(targets, toolsets, tools) and only mentions the file in passing. It now opens
with a pointer to the Configuration page, which documents the file's keys,
workspace defaults, and precedence.

Generator change (ExternalConfigDocsGenerator) + regenerated output.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants