Add support for Claude's "adaptive" and "auto" thinking modes using `output_config.effort`. Introduce support for new effort level "max" in adaptive thinking. Update thinking logic, validate model capabilities, and extend converters and handling to ensure compatibility with adaptive modes. Adjust static model data with supported levels and refine handling across translators and executors.
## Problem
When using Antigravity Claude models through CLIProxyAPI, the thinking
chain (reasoning content) does not display in the Amp client.
## Root Cause
The Amp client sends `thinking: {"type": "auto"}` in its requests,
but `ConvertClaudeRequestToAntigravity` only handled `"enabled"` and
`"adaptive"` types in its switch statement. The `"auto"` type was
silently ignored, resulting in no `thinkingConfig` being set in the
translated Gemini request. Without `thinkingConfig`, the Antigravity
API returns responses without any thinking content.
Additionally, the Antigravity API for Claude models does not support
`thinkingBudget: -1` (auto mode sentinel). It requires a concrete
positive budget value. The fix uses 128000 as the budget for "auto"
mode, which `ApplyThinking` will then normalize to stay within the
model's actual limits (e.g., capped to `maxOutputTokens - 1`).
## Changes
### internal/translator/antigravity/claude/antigravity_claude_request.go
1. **Add "auto" case** to the thinking type switch statement.
Sets `thinkingBudget: 128000` and `includeThoughts: true`.
The budget is subsequently normalized by `ApplyThinking` based
on model-specific limits.
2. **Add "auto" to hasThinking check** so that interleaved thinking
hints are injected for tool-use scenarios when Amp sends
`thinking.type="auto"`.
### internal/registry/model_definitions_static_data.go
3. **Add Thinking configuration** for `claude-sonnet-4-6`,
`claude-sonnet-4-5`, and `claude-opus-4-6` in
`GetAntigravityModelConfig()` -- these were previously missing,
causing `ApplyThinking` to skip thinking config entirely.
## Testing
- Deployed to Railway test instance (cpa-thinking-test)
- Verified via debug logging that:
- Amp sends `thinking: {"type": "auto"}`
- CPA now translates this to `thinkingConfig: {thinkingBudget: 128000, includeThoughts: true}`
- `ApplyThinking` normalizes the budget to model-specific limits
- Antigravity API receives the correct thinkingConfig
Amp-Thread-ID: https://ampcode.com/threads/T-019ca511-710d-776d-a07c-4b750f871a93
Co-authored-by: Amp <amp@ampcode.com>
- Introduced unit tests for request logging middleware to enhance coverage.
- Added WebSocket-based Codex executor to support Responses API upgrade.
- Updated middleware logic to selectively capture request bodies for memory efficiency.
- Enhanced Codex configuration handling with new WebSocket attributes.
- OAuth2 device authorization grant flow (RFC 8628) for authentication
- Streaming and non-streaming chat completions via OpenAI-compatible API
- Models: kimi-k2, kimi-k2-thinking, kimi-k2.5
- CLI `--kimi-login` command for device flow auth
- Token management with automatic refresh
- Thinking/reasoning effort support for thinking-enabled models
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Claude Haiku 4.5 (claude-haiku-4-5-20251001) supports extended thinking
according to Anthropic's official documentation:
https://docs.anthropic.com/en/docs/build-with-claude/extended-thinking
The model was incorrectly marked as not supporting thinking in the static
model definitions. This fix adds ThinkingSupport with the same parameters
as other Claude 4.5 models (Sonnet, Opus):
- Min: 1024 tokens
- Max: 128000 tokens
- ZeroAllowed: true
- DynamicAllowed: false
Add support for Imagen 3.0 and 4.0 image generation models in Vertex AI:
- Add 5 Imagen model definitions (4.0, 4.0-ultra, 4.0-fast, 3.0, 3.0-fast)
- Implement :predict action routing for Imagen models
- Convert Imagen request/response format to match Gemini structure like gemini-3-pro-image
- Transform prompts to Imagen's instances/parameters format
- Convert base64 image responses to Gemini-compatible inline data
Added support for external hooks to observe model registry events using the `ModelRegistryHook` interface. Implemented thread-safe, non-blocking execution of hooks with panic recovery. Comprehensive tests added to verify hook behavior during registration, unregistration, blocking, and panic scenarios.
