400 Bad Request with Anthropic models when using custom tools with nested object schemas

[Tarquinen]

Summary

Anthropic models via the antigravity provider fail with a 400 Bad Request when custom tools contain nested object schemas with enums, optional fields, and record types.

Environment

• Branch: dev
• Provider: antigravity
• Model: antigravity/claude-opus-4-5

Tool Schema That Causes the Issue

description: TOOL_DESCRIPTION,
args: {
    ids: tool.schema.array(
        tool.schema.string()
    ).describe(
        "Numeric IDs as strings to prune from the <prunable-tools> list"
    ),
    metadata: tool.schema.object({
        reason: tool.schema.enum(["completion", "noise", "consolidation"]).describe("The reason for pruning"),
        distillation: tool.schema.record(tool.schema.string(), tool.schema.any()).optional().describe(
            "An object containing detailed summaries or extractions of the key findings from the tools being pruned. This is REQUIRED for 'consolidation'."
        ),
    }).describe("Metadata about the pruning operation."),
},

Error Output

Acquiring credential for model antigravity/claude-opus-4-5. Tried credentials: 0/1(5)
Acquired key antigravity_oauth_1.json for model antigravity/claude-opus-4-5 (tier: standard-tier, priority: 2, selection: sequential, quota: 2/250 [99%])
Attempting stream with credential antigravity_oauth_1.json (Attempt 1/2)
Stream connection established for credential antigravity_oauth_1.json. Processing response.
Caught a critical API error mid-stream: HTTPStatusError. Signaling for credential rotation.
Released credential antigravity_oauth_1.json from model antigravity/claude-opus-4-5 (remaining concurrent: 0)
STREAM FINISHED and lock released for credential antigravity_oauth_1.json.
API call failed for model antigravity/claude-opus-4-5 with key antigravity_oauth_1.json. Error: StreamedAPIError. See failures.log for details.
Non-recoverable error (invalid_request) during custom stream. Failing.
An unhandled exception occurred in streaming retry logic: Provider error received in stream

Full Traceback

Traceback (most recent call last):
  File "/home/dan/src/LLM-API-Key-Proxy/src/rotator_library/client.py", line 690, in _safe_streaming_wrapper
    chunk = await stream_iterator.__anext__()
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/dan/src/LLM-API-Key-Proxy/src/rotator_library/providers/antigravity_provider.py", line 4671, in _streaming_with_retry
    async for chunk in self._handle_streaming(
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<9 lines>...
        yield chunk  # Stream immediately - true streaming preserved
        ^^^^^^^^^^^
  File "/home/dan/src/LLM-API-Key-Proxy/src/rotator_library/providers/antigravity_provider.py", line 4545, in _handle_streaming
    response.raise_for_status()
    ~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/home/dan/src/LLM-API-Key-Proxy/venv/lib/python3.13/site-packages/httpx/_models.py", line 829, in raise_for_status
    raise HTTPStatusError(message, request=request, response=self)
httpx.HTTPStatusError: Client error '400 Bad Request' for url 'https://daily-cloudcode-pa.sandbox.googleapis.com/v1internal:streamGenerateContent?alt=sse'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/dan/src/LLM-API-Key-Proxy/src/rotator_library/client.py", line 1925, in _streaming_acompletion_with_retry
    raise last_exception
  File "/home/dan/src/LLM-API-Key-Proxy/src/rotator_library/client.py", line 1888, in _streaming_acompletion_with_retry
    async for chunk in stream_generator:
        yield chunk
  File "/home/dan/src/LLM-API-Key-Proxy/src/rotator_library/client.py", line 783, in _safe_streaming_wrapper
    raise StreamedAPIError("Provider error received in stream", data=e)
rotator_library.client.StreamedAPIError: Provider error received in stream

Additional Notes

• Nothing is logged to failures.log despite the error message suggesting it should be
• The issue appears to be related to how nested object schemas with enum, optional, and record types are being converted/passed to the Gemini API endpoint
• The 400 error comes from Google's internal endpoint (daily-cloudcode-pa.sandbox.googleapis.com), suggesting the tool schema conversion to Gemini format may be malformed

---

@MirRobot please analyze this issue and open a PR with a fix.

[mirrobot-agent]

@Tarquinen Thank you for submitting this issue. I am now beginning my analysis and will report back shortly.

[mirrobot-agent]

Initial Analysis Report

Summary: The issue is caused by the _clean_claude_schema function's handling of nested object schemas with anyOf/oneOf patterns (used for optional .record() types) - taking only the first option loses type information and may produce malformed schemas for Google's API.

Issue Validation: Confirmed

Reproducibility Assessment: Reproducible - The schema pattern in the issue (nested object with enum, .optional(), and .record()) will trigger the identified code paths.

Root Cause Analysis:

The issue stems from multiple schema transformation problems in src/rotator_library/providers/antigravity_provider.py:

1. anyOf/oneOf handling loses nested type info (lines 422-432):
   When a field is marked as .optional() in the tool schema DSL, it typically generates an anyOf: [{actualType}, {type: "null"}] pattern. The current code (_clean_claude_schema) takes only the first option, which works for simple cases but fails for complex nested objects:

   # Current behavior - takes first option blindly
   if "anyOf" in schema and isinstance(schema["anyOf"], list) and schema["anyOf"]:
       first_option = _clean_claude_schema(schema["anyOf"][0])
       if isinstance(first_option, dict):
           return first_option

   For .record(schema.string(), schema.any()).optional(), this could lose the additionalProperties or patternProperties that define the record type.

2. additionalProperties is stripped but needed for record types (line 392):
   The _clean_claude_schema function strips additionalProperties from schemas. However, tool.schema.record() generates schemas that rely on additionalProperties to define the value type for arbitrary keys. Stripping this makes the schema structurally invalid for Google's API.

3. Potential order-of-operations issue with anyOf containing null:
   If .optional() generates anyOf: [{type: "object", properties: {...}}, {type: "null"}], and the code takes the first option (the object), it should work. But if the order is reversed or there are additional transformations, the schema could be corrupted.

4. Secondary issue - No failures.log entry:
   The user reports nothing is logged to failures.log despite the error. Looking at the code flow:

   • The error occurs in antigravity_provider.py during streaming (line 4545)
   • It's caught in client.py and should call log_failure() (line 1876)
   • This suggests either: (a) the logs directory doesn't exist or isn't writable, or (b) the streaming error is being re-raised before log_failure is called

Key Files Involved:

• src/rotator_library/providers/antigravity_provider.py:
  • _clean_claude_schema() (lines 378-453): Main schema sanitization
  • _build_tools_payload() (lines 2522-2582): Tool transformation pipeline
  • _apply_claude_tool_transform() (lines 2702-2717): Claude-specific processing
• src/rotator_library/failure_logger.py: Logging infrastructure
• src/rotator_library/client.py: Error handling and retry logic

Suggested Labels: bug, provider:antigravity, priority:high

Proposed Next Steps:

1. Fix _clean_claude_schema to properly handle anyOf with nullable types:

   # Proposed fix: Handle anyOf for nullable types without losing type info
   if "anyOf" in schema and isinstance(schema["anyOf"], list):
       # Check if this is a nullable pattern (type + null)
       non_null_options = [opt for opt in schema["anyOf"] 
                          if opt.get("type") != "null"]
       if len(non_null_options) == 1:
           # This is just making a type nullable - use the non-null type
           return _clean_claude_schema(non_null_options[0])
       elif len(non_null_options) > 1:
           # Multiple real types - take first (existing behavior)
           return _clean_claude_schema(non_null_options[0])

2. Preserve additionalProperties for record/map types:

   • The schema cleaner should NOT strip additionalProperties when its value defines a type (i.e., additionalProperties: {type: "string"}), only when it's true or false.

3. Add debug logging for transformed schemas:

   • Log the before/after of schema transformation to help diagnose future issues.

4. Investigate failures.log not being written:

   • Check if the streaming error flow bypasses log_failure() for certain exception types.

Missing Information (if any):

• The exact JSON schema being generated from the tool definition would help confirm the root cause. Could you add debug logging to capture func_decl["parametersJsonSchema"] after line 2547 in _build_tools_payload() and share the output?

---

This analysis was generated by an AI assistant.

[Tarquinen]

good boy

[Mirrowel]

Issue analysis is most likely wrong. Without the error not much can be done. I'll investigate by reproducing.

Actually @mirrobot-agent check what changes to Claude schema conversion were done on dev vs main - maybe issue is there

[mirrobot-agent]

@Mirrowel, understood. I'll compare the dev and main branches to identify what changes were made to the Claude schema conversion code. This will help determine if a recent change introduced the issue.

Starting investigation now...

[mirrobot-agent]

@Mirrowel, I've completed my analysis of the differences between dev and main for the Claude schema conversion code. Here's what I found:

Summary

There have been significant changes to the _clean_claude_schema function and related schema handling between main and dev. The changes were made across several commits, with the most relevant ones being:

1. 1ec1463 - refactor(antigravity): 🔨 improve additionalProperties handling in schema cleaning
2. 740e192 - fix(antigravity): 🐛 preserve property names matching validation keywords
3. e4ee46f - fix(antigravity): 🐛 TLDR: Huge ass pass fixing things + Gemini 3 Flash addition

Key Differences

1. New for_gemini Parameter (commit e4ee46f)

The _clean_claude_schema function now accepts a for_gemini: bool = False parameter that changes behavior:

For Claude (for_gemini=False):

• Converts anyOf/oneOf to first option (unchanged from main)
• Converts const to enum (unchanged)
• Strips validation keywords like $schema, pattern, format, default, etc.
• NEW: Normalizes permissive additionalProperties (true or {}) to true
• NEW: Skips complex additionalProperties schemas (e.g., {"type": "string"})

For Gemini (for_gemini=True):

• Passes through anyOf, oneOf, const as-is
• Passes through additionalProperties as-is
• Preserves more validation keywords

2. additionalProperties Handling Changed (commit 1ec1463)

On main:

• additionalProperties was in the incompatible list and always stripped

On dev:

• additionalProperties is now handled specially:
  • For Claude: true or {} → preserved as true; false → preserved; complex schemas → skipped
  • For Gemini: passed through as-is

3. Code Flow Issue

Looking at the call sites:

1. In _build_tools_payload (line 3420 on dev):

   is_gemini = not self._is_claude(model)
   schema = _clean_claude_schema(schema, for_gemini=is_gemini)

   This correctly passes for_gemini=False for Claude models.

2. In _apply_claude_tool_transform (line 3597 on dev):

   params = _clean_claude_schema(params)  # NO for_gemini parameter!

   This is called for Claude models but doesn't pass for_gemini=False explicitly (defaults to False, so OK).

Potential Issues Identified

Issue A: Complex additionalProperties Silently Dropped for Claude

The tool schema in the issue uses:

distillation: tool.schema.record(tool.schema.string(), tool.schema.any()).optional()

A .record() type typically generates:

{
  "type": "object",
  "additionalProperties": {"type": "string"}
}

On dev, when for_gemini=False (Claude path), this complex additionalProperties is silently skipped, leaving the object schema without any additionalProperties definition. This could result in a malformed schema for Google's API.

Issue B: anyOf for Optional Fields

The .optional() modifier often generates anyOf: [{actualType}, {type: "null"}]. On dev, for Claude:

• Takes the first option blindly
• If the order is [{type: "null"}, {actualType}], it would incorrectly return {type: "null"}

This is unchanged from main, but combined with the new additionalProperties handling, could cause issues.

Conclusion

The most likely culprit is the new additionalProperties handling in commit 1ec1463. When a tool has a nested object with additionalProperties: {"type": "string"} (from .record()), the dev branch now silently drops this instead of stripping it entirely, potentially leaving the schema in an inconsistent state that Google's API rejects.

Suggested Fix

In _clean_claude_schema, for Claude models, when encountering a complex additionalProperties schema, instead of silently skipping it, normalize it to true (permissive):

if key == "additionalProperties":
    if for_gemini:
        cleaned["additionalProperties"] = value
    else:
        # Claude: normalize ANY additionalProperties to a simple form
        if value is False:
            cleaned["additionalProperties"] = False
        else:
            # True, {}, or complex schema -> normalize to true
            cleaned["additionalProperties"] = True
    continue

This ensures the schema remains structurally valid while still being compatible with Claude via Antigravity.

---

This analysis was generated by an AI assistant.

[Tarquinen]

Issue exists in main and dev

[Tarquinen]

@mirrobot-agent the fix is to add "propertyNames" to the validation_keywords_claude_only list (around line 550) in rotator_library/providers/antigravity_provider.py . Now go fix it clanker.

[mirrobot-agent]

@Tarquinen, I'm on it. I'll add propertyNames to the validation_keywords_claude_only list in the antigravity provider and open a PR with the fix.

Starting implementation now...

[Tarquinen]

good boy

[mirrobot-agent]

@Tarquinen, I've successfully implemented the fix and created a pull request.

Summary

Added propertyNames to the incompatible set in the _clean_claude_schema() function, which strips unsupported JSON Schema validation keywords before sending tool definitions to Google's Proto-based API.

Key Changes Made

• File: src/rotator_library/providers/antigravity_provider.py
• Location: Line 407 in the incompatible set within _clean_claude_schema()
• Change: Added "propertyNames" to the list of keywords that get stripped from tool schemas

The Fix

The _clean_claude_schema() function already strips many unsupported JSON Schema keywords. The propertyNames keyword (used for validating property names in objects) was missing from this list, causing 400 Bad Request errors when tool schemas contained this keyword.

incompatible = {
    # ... existing keywords ...
    "minProperties",
    "maxProperties",
    "propertyNames",  # <-- Added
    "uniqueItems",
    # ... remaining keywords ...
}

Pull Request Created

#52

---

This update was generated by an AI assistant.

[Tarquinen]

@mirrorbot-agent good, now merge it into dev

[Tarquinen]

@mirrorbot-agent fix the conflicts in that PR