Skip to content

feat(ollama): detect model capabilities dynamically via /api/show#5114

Open
intel352 wants to merge 3 commits intogenkit-ai:mainfrom
GoCodeAlone:feat/ollama-dynamic-tool-capabilities
Open

feat(ollama): detect model capabilities dynamically via /api/show#5114
intel352 wants to merge 3 commits intogenkit-ai:mainfrom
GoCodeAlone:feat/ollama-dynamic-tool-capabilities

Conversation

@intel352
Copy link
Copy Markdown

Summary

Replace the hardcoded toolSupportedModels and mediaSupportedModels allowlists in the Ollama plugin with dynamic capability detection from Ollama's /api/show endpoint.

Problem

The Ollama plugin maintains static string arrays of model names that support tools and media. Newly released models (e.g. gemma4, which Ollama reports as tool-capable via its API) don't work with tool calling until someone manually updates these lists and ships a new Genkit release. This creates an unnecessary maintenance burden and blocks users from using new models with tools.

Solution

Ollama's POST /api/show endpoint returns a capabilities array (e.g. ["completion", "vision", "tools", "thinking"]) that accurately reports what each model supports. This PR queries that endpoint when determining model capabilities, falling back to the existing static lists when the server doesn't report capabilities (older Ollama versions).

Changes

  • go/plugins/ollama/ollama.go:
    • Add getModelCapabilities() — queries /api/show for a model's capabilities
    • Add modelSupportsFromCapabilities() — derives ModelSupports from capability strings, with static-list fallback
    • Update DefineModel() to use dynamic detection when no explicit opts provided
    • Update ListActions() and ResolveAction() to use dynamic detection
  • go/plugins/ollama/ollama_test.go:
    • Add TestGetModelCapabilities — mock server tests for tools/no-tools/unknown models
    • Add TestModelSupportsFromCapabilities — unit tests for dynamic and fallback paths

Backward Compatibility

  • When /api/show returns capabilities → used directly (new behavior)
  • When /api/show doesn't return capabilities or fails → falls back to existing static allowlists (existing behavior preserved)
  • Explicit ModelOptions passed to DefineModel() are still respected (no change)

Testing

All existing tests pass. New tests cover:

  • Capability detection from mock /api/show endpoint
  • Fallback to static lists when no capabilities reported
  • Models in the static list still work via fallback
  • Unknown models default to no tools/media

🤖 Generated with Claude Code

Replace the hardcoded toolSupportedModels and mediaSupportedModels
allowlists with dynamic capability detection from Ollama's /api/show
endpoint. This ensures newly released models (e.g. gemma4) work
automatically without code changes.

The /api/show response includes a "capabilities" array (e.g.
["completion", "vision", "tools", "thinking"]) that accurately
reports what each model supports. This is more reliable than a
static allowlist that requires manual updates for every new model.

Fallback behavior: when /api/show doesn't return capabilities
(older Ollama versions), the existing static allowlists are used
as a fallback, preserving backward compatibility.

Changes:
- Add getModelCapabilities() to query /api/show for a model
- Add modelSupportsFromCapabilities() to derive ModelSupports
- Update DefineModel() to use dynamic detection
- Update ListActions() and ResolveAction() to use dynamic detection
- Add tests for capability detection and fallback behavior
@google-cla
Copy link
Copy Markdown

google-cla bot commented Apr 13, 2026

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

@github-actions github-actions bot added the go label Apr 13, 2026
Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request replaces hardcoded model capability allowlists with dynamic capability detection by querying the Ollama /api/show endpoint. This allows newly released models to work automatically without code changes. Feedback focuses on performance and reliability concerns regarding network I/O, specifically recommending the use of contexts with timeouts to prevent hanging requests, checking for context cancellation in loops, and avoiding I/O operations while holding mutexes to prevent resource contention.

Comment thread go/plugins/ollama/ollama.go Outdated
Comment thread go/plugins/ollama/ollama.go
Comment thread go/plugins/ollama/ollama.go Outdated
…lation check

- DefineModel: detect capabilities before acquiring o.mu to avoid blocking
  the lock on HTTP I/O; use context.WithTimeout instead of context.Background()
- ListActions: check ctx.Err() before each sequential /api/show call so
  a cancelled context stops the loop immediately
- ResolveAction: use context.WithTimeout(o.Timeout) instead of bare
  context.Background() so the capability query is bounded
The previous fix moved I/O outside the lock but left the initted guard
after it, so a missing Init() would hang for Timeout seconds. Now:
1. Briefly lock, check o.initted, unlock immediately (panic if not init'd)
2. Do HTTP capability detection without holding the lock
3. Re-acquire lock for model registration
@intel352 intel352 force-pushed the feat/ollama-dynamic-tool-capabilities branch from 30edb68 to 26ef251 Compare April 13, 2026 20:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant