You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG] Anti-gravity models fail with enum TYPE_STRING validation error in memory_rate_memory tool #8034
When using anti-gravity models in OpenCode, the following validation error occurs:
Invalid value at 'request.tools[0].function_declarations[33].parameters.properties[1].value.enum[0]' (TYPE_STRING), -1
Invalid value at 'request.tools[0].function_declarations[33].parameters.properties[1].value.enum[1]' (TYPE_STRING), 0
Invalid value at 'request.tools[0].function_declarations[33].parameters.properties[1].value.enum[2]' (TYPE_STRING), 1
Root Cause
The memory_rate_memory tool (function_declarations[33]) has a rating parameter with numeric enum values [-1, 0, 1], but the anti-gravity model API requires enum values to be strings, not numbers.
Expected Behavior
The tool should work with anti-gravity models without validation errors.
Actual Behavior
Anti-gravity models reject the tool schema due to type mismatch in enum values.
Proposed Solution
Update the memory_rate_memory tool definition to use string enum values:
Change enum: [-1, 0, 1] to enum: ["-1", "0", "1"]
Or remove the enum constraint and use type validation with description
Environment
OpenCode version: latest
Model provider: Anti-gravity models
Platform: Linux
Additional Context
This issue only occurs with anti-gravity models. Other model providers appear to have more lenient schema validation and accept numeric enum values.
The root cause appears to be a pattern where tool parameter schemas use incorrect types (numeric enums instead of string enums, missing field definitions, etc.) that different model providers reject during validation. Feel free to ignore if none of these address your specific case.
Activity
github-actions commentedon Jan 12, 2026
This issue might be a duplicate of existing issues. Please check:
The root cause appears to be a pattern where tool parameter schemas use incorrect types (numeric enums instead of string enums, missing field definitions, etc.) that different model providers reject during validation. Feel free to ignore if none of these address your specific case.