Model Test

Overview

The model test feature (also known as Stream Check) verifies whether a provider's configured model is available by sending actual API requests to test:

• Whether the model exists
• Whether the API Key is valid
• Whether the endpoint responds normally
• Whether the response latency is acceptable
• Time to first token (TTFB) for streaming responses

Starting from v3.13.0, Stream Check coverage is extended to Claude / Codex / Gemini / OpenCode / OpenClaw, including all OpenClaw protocol variants (such as openai-completions). OpenCode is auto-detected via npm package mapping; OpenClaw supports custom auth-header detection and handles edge cases like Bedrock error messages and baseURL fallback.

For Codex third-party providers that use the Chat Completions protocol (such as DeepSeek, Kimi, or MiniMax), Stream Check probes the /chat/completions endpoint (instead of /responses) and aligns its URL fallback order with the actual proxy forwarding path (origin-only addresses try /v1/... first), so a working provider is not mistakenly flagged as unavailable.

Open Configuration

Settings > Advanced > Model Test Config

Test Model Configuration

Configure the model used for testing per application:

Model Selection Tips

When choosing a test model, consider:

1. Cost: Choose lower-priced models (e.g., Haiku, Mini, Flash)
2. Speed: Choose fast-responding models
3. Availability: Choose models supported by the provider

Test Parameter Configuration

Timeout

Setting it too short may cause false negatives; too long delays fault detection.

Retries

Increase retries when the network is unstable.

Degradation Threshold

Providers exceeding the threshold are marked as "degraded" but remain usable.

Execute Model Test

Manual Test

Click the "Test" button on the provider card:

1. Sends a test request to the configured endpoint
2. Uses the configured test model
3. Waits for response or timeout
4. Displays the test result

Test Content

The test request:

• Sends a short prompt (e.g., "Hi")
• Limits maximum output tokens (typically 10-50)
• Uses streaming response to detect time to first byte

Test Results

Health Status

Result Information

After testing completes, displays:

• Response latency (milliseconds)
• Time to first byte (TTFB)
• Error message (if failed)

Integration with Failover

Model testing works in conjunction with the failover feature:

Health Checks

After enabling the proxy service, the system periodically performs health checks on providers in the failover queue:

1. Sends a request using the configured test model
2. Updates health status based on the response
3. Unhealthy providers are temporarily skipped

Circuit Breaker Recovery

When a provider recovers from a circuit-broken state:

1. Performs a model test to verify availability
2. If the test passes, normal status is restored
3. If the test fails, the circuit breaker remains active

FAQ

Test Fails But Actually Available

Possible causes:

• The test model differs from the actually used model
• The provider doesn't support the configured test model

Solutions:

• Change the test model to one supported by the provider
• Check the provider's model list

High Latency

Possible causes:

• Network latency
• High server load on the provider
• Slow model response

Solutions:

• Use a faster test model
• Adjust the degradation threshold
• Consider using mirror endpoints

Frequent Timeouts

Possible causes:

• Timeout set too short
• Unstable network
• Unstable provider service

Solutions:

• Increase the timeout
• Increase retry count
• Check network connection

Notes

• Model testing consumes a small amount of API quota
• Recommend using low-cost models for testing
• Testing frequency should not be too high to avoid wasting quota
• Different providers may support different models