feat(openai_compat): implement strict mode compatibility for third-party providers by badgerbees · Pull Request #1683 · sipeed/picoclaw

badgerbees · 2026-03-17T10:24:08Z

📝 Description

Summary:

Implement OpenAI Strict Mode compatibility for the openai_compat provider.
Fail-Safe Sanitization: Automatically strip the strict: true flag from tool definitions for non-native OpenAI providers (Ollama, vLLM, DeepSeek, Groq, etc.).

Changes:

pkg/providers/openai_compat/provider.go:
- Added finalizeTools helper to sanitize tool definitions before wire serialization.
- Implemented supportsStrictMode to detect native OpenAI/Azure endpoints based on the API base URL.
- Updated Chat() to utilize lazy tool sanitization.

🗣️ Type of Change

🐞 Bug fix (non-breaking change which fixes an issue)
✨ New feature (non-breaking change which adds functionality)
📖 Documentation update
⚡ Code refactoring (no functional changes, no api changes)

🤖 AI Code Generation

🤖 Fully AI-generated (100% AI, 0% Human)
🛠️ Mostly AI-generated (AI draft, Human verified/modified)
👨‍💻 Mostly Human-written (Human lead, AI assisted or none)

🔗 Related Issue

N/A

📚 Technical Context (Skip for Docs)

Problem Overview:
Many "OpenAI-compatible" providers (like Ollama or Groq) strictly reject unknown fields in the tool definition JSON. Specifically, OpenAI's new "strict": true flag for Structured Outputs causes these providers to return 400 Bad Request or 422 Unprocessable Entity errors, crashing tool calls in PicoClaw.
Solution Implementation:
- Environment Detection: The provider now checks if the apiBase is native OpenAI.
- Selective Sanitization: If the provider is non-native, we strip the strict flag by rebuilding the tool map with only standard fields.
- Passthrough Optimization: For native OpenAI, the code passes the tool array through as-is, preserving original behavior and avoiding performance overhead.

🧪 Test Environment

Hardware: PC
OS: Windows / WSL (Ubuntu)
Model/Provider: DeepSeek, Ollama, Groq (via openai_compat)
Channels: All (Core Provider fix)

📸 Evidence (Optional)

Click to view Logs/Test Results

Test Results:

Passed go test ./pkg/providers/openai_compat/...
Verified compatibility with non-strict schemas on official OpenAI.
Verified removal of incompatible flags on mock non-native endpoints.

☑️ Checklist

My code/docs follow the style of this project.
I have performed a self-review of my own changes.
I have updated the documentation accordingly.

Copilot

Pull request overview

Implements OpenAI Structured Outputs “strict mode” handling in the openai_compat provider by conditionally sanitizing tool definitions for non-native OpenAI endpoints, and optionally injecting function.strict based on endpoint detection and a caller-provided toggle.

Changes:

Route tools through a new finalizeTools helper before JSON serialization.
Add supportsStrictMode (currently mirroring the existing OpenAI/Azure detection logic).
Add strict-mode sanitization / injection logic with an options["strict_mode"] override.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

pkg/providers/openai_compat/provider.go

 	if len(tools) > 0 {
-		requestBody["tools"] = tools
+		requestBody["tools"] = p.finalizeTools(tools, options)
 		requestBody["tool_choice"] = "auto"
 	}


yinwm

Code Review

Overall: ✅ Ready to merge with minor suggestions

1. Logic Issue ⚠️

strict_mode=true forced on non-native providers may still cause errors

useStrict := isNative
if hasForce {
    useStrict = forceStrict
}

When a user sets strict_mode=true but the provider is Ollama/Groq/DeepSeek (non-native OpenAI), the code will still send strict=true in the request, which will still result in a 400 error.

Suggestion: Either log a warning or ignore the forced setting when the provider doesn't support it:

if hasForce && forceStrict && !isNative {
    // slog.Warn("strict_mode=true ignored for non-OpenAI provider", "provider", p.apiBase)
    useStrict = false
}

2. Potential Edge Case 🔍

The ToolFunctionDefinition struct doesn't have a Strict field. This PR assumes strict is controlled via options, not already present in the input tools.

Question: Could the tools parameter already contain a strict field from upstream? If so, the current sanitization logic won't remove it since it only rebuilds with standard fields.

3. Code Quality 👍

✅ Clear comments explaining the performance optimization path
✅ Good reuse of supportsPromptCacheKey detection logic
✅ Pass-through optimization avoids unnecessary memory allocation

4. Missing Items 📋

Item	Status
Unit tests	❌ Missing
Documentation for `strict_mode` option	❌ Not mentioned
Edge case: `forceStrict=true` + non-native provider	⚠️ Not handled

5. Suggested Improvement

func (p *Provider) finalizeTools(tools []ToolDefinition, options map[string]any) any {
    forceStrict, hasForce := options["strict_mode"].(bool)
    isNative := supportsStrictMode(p.apiBase)

    // Fast path: native OpenAI without forced setting
    if isNative && !hasForce {
        return tools
    }

    // Decide whether to use strict mode
    useStrict := isNative
    if hasForce {
        if forceStrict && !isNative {
            // Non-native providers don't support strict mode, ignore user setting
            // slog.Warn("strict_mode=true ignored for non-OpenAI provider", "provider", p.apiBase)
            useStrict = false
        } else {
            useStrict = forceStrict
        }
    }

    // ... rest unchanged
}

Conclusion

The core logic is correct and solves a real compatibility issue. Recommend merging after addressing the strict_mode=true edge case (or at least adding a warning log). Unit tests would be a nice addition.

…add unit tests

badgerbees · 2026-03-17T16:17:27Z

I've updated the branch to address the review feedback:

Refined Strict Mode Logic: I've implemented the suggested check to prevent 400 errors on non-native providers. If a user tries to force strict_mode: true for a provider like Ollama or Groq, the system now logs a warning and safely falls back to non-strict mode for that request.
Request Sanitization: To address the edge case of field leakage, finalizeTools now rebuilds the tool map from scratch using an explicit field allow-list (name, description, parameters). This effectively 'sanitizes' the output, ensuring no unsupported fields (like a pre-existing strict field from upstream) can reach the final API request.
Unit Tests: Added TestFinalizeTools_StrictMode to verify native detection, automatic stripping for non-native providers, and the behavior of explicit user overrides.

The implementation is now robust against unsupported field errors while maintaining flexible control for native OpenAI endpoints.

yinwm · 2026-03-17T17:03:34Z

@badgerbees plz fix PR Linter / tests

badgerbees · 2026-03-17T17:07:14Z

@badgerbees plz fix PR Linter / tests

what the hell there were literally no issues with it when I ran the checks hence the workflow working the first time, I've no idea what these errors meant either + I've just checked again and there were no lint error

let me take a look again since all workflow failed too not just 1

badgerbees · 2026-03-17T17:11:30Z

huh strange all the errors are related to log being undefined yet last workflow it was fine, I guess I'll fix them then

Copilot

Pull request overview

Implements OpenAI “Strict Mode” compatibility behavior in the openai_compat provider by conditionally adding/removing the strict tool flag depending on whether the configured endpoint is native OpenAI/Azure vs a third-party OpenAI-compatible API.

Changes:

Route tool serialization through a new finalizeTools helper to optionally inject/strip function.strict.
Add strict-mode support detection (supportsStrictMode) based on API base hostname (mirrors prompt cache support detection).
Add unit coverage for strict tool finalization behavior across native vs non-native API bases.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
pkg/providers/openai_compat/provider.go	Adds strict-mode detection and tool finalization, and updates `Chat()` to use it.
pkg/providers/openai_compat/provider_test.go	Adds tests covering strict-mode tool finalization behavior and pass-through expectations.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

pkg/providers/openai_compat/provider.go

pkg/providers/openai_compat/provider_test.go

+			res := p.finalizeTools(tools, tt.options)
+
+			if tt.wantSame {
+				if fmt.Sprintf("%p", res) != fmt.Sprintf("%p", tools) {


…h slog

badgerbees · 2026-03-17T17:25:08Z

The previous CI failure (undefined: log) was due to an out-of-sync merge with the latest refactor in main, which replaced the standard log package with slog.

I've fixed this by:

Switching to slog: All logging in provider.go (including the new Strict Mode warning) now uses the new structured logging system.
Updating to the common Package: Updated the provider to use the new pkg/providers/common utilities for message serialization and response parsing that were recently merged.
Local Verification: Confirmed that go test ./pkg/providers/openai_compat/... passes locally with the new structure.

…ility and resolve conflicts

feat(openai_compat): implement strict mode compatibility check

5675cf3

Copilot AI review requested due to automatic review settings March 17, 2026 10:24

Copilot started reviewing on behalf of badgerbees March 17, 2026 10:24 View session

Copilot AI reviewed Mar 17, 2026

View reviewed changes

sipeed-bot bot added type: enhancement New feature or request domain: provider go Pull requests that update go code labels Mar 17, 2026

yinwm reviewed Mar 17, 2026

View reviewed changes

address review feedback: handle non-native strict mode edge case and …

0986e2e

…add unit tests

badgerbees requested a review from yinwm March 17, 2026 16:17

Merge branch 'sipeed:main' into feature/openai-strict-mode-compatibility

a10f3fd

Copilot AI review requested due to automatic review settings March 17, 2026 17:12

Copilot started reviewing on behalf of badgerbees March 17, 2026 17:13 View session

Copilot AI reviewed Mar 17, 2026

View reviewed changes

pkg/providers/openai_compat/provider.go Outdated Show resolved Hide resolved

pkg/providers/openai_compat/provider_test.go Outdated

res := p.finalizeTools(tools, tt.options)

if tt.wantSame {

if fmt.Sprintf("%p", res) != fmt.Sprintf("%p", tools) {

fix: resolve merge conflicts and update to new provider structure wit…

6b8d8bc

…h slog

badgerbees and others added 4 commits March 18, 2026 22:29

fix: resolve merge conflict - combine strict mode with native search

d54b6f5

Merge branch 'main' into feature/openai-strict-mode-compatibility

b721825

Merge branch 'upstream/main' into feature/openai-strict-mode-compatib…

7a0ad5f

…ility and resolve conflicts

Merge origin branch and resolve conflicts

322de74

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(openai_compat): implement strict mode compatibility for third-party providers#1683

feat(openai_compat): implement strict mode compatibility for third-party providers#1683
badgerbees wants to merge 8 commits intosipeed:mainfrom
badgerbees:feature/openai-strict-mode-compatibility

badgerbees commented Mar 17, 2026 •

edited

Loading

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

yinwm left a comment

Uh oh!

badgerbees commented Mar 17, 2026

Uh oh!

yinwm commented Mar 17, 2026

Uh oh!

badgerbees commented Mar 17, 2026

Uh oh!

badgerbees commented Mar 17, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Uh oh!

badgerbees commented Mar 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

badgerbees commented Mar 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

📝 Description

🗣️ Type of Change

🤖 AI Code Generation

🔗 Related Issue

📚 Technical Context (Skip for Docs)

🧪 Test Environment

📸 Evidence (Optional)

☑️ Checklist

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

yinwm left a comment

Choose a reason for hiding this comment

Code Review

Overall: ✅ Ready to merge with minor suggestions

1. Logic Issue ⚠️

2. Potential Edge Case 🔍

3. Code Quality 👍

4. Missing Items 📋

5. Suggested Improvement

Conclusion

Uh oh!

badgerbees commented Mar 17, 2026

Uh oh!

yinwm commented Mar 17, 2026

Uh oh!

badgerbees commented Mar 17, 2026

Uh oh!

badgerbees commented Mar 17, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

badgerbees commented Mar 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

badgerbees commented Mar 17, 2026 •

edited

Loading