GPT-6 Sol/Luna tool calling: fix the request before migrating
Check Responses versus Chat Completions, reasoning settings and unsupported parameters for GPT-6 Sol and Luna. Includes a local request checker.
For GPT-6 Sol or Luna with reasoning and function calls, use the Responses API. Chat Completions supports function calling for these models only with reasoning_effort set to none, according to the current official model guidance. A client that sends plain text successfully can therefore still need changes before its agent loop works.
This guide follows OpenAI’s migration guidance and the Sol and Luna model pages, checked September 23, 2026. It checks documented request compatibility. It does not invent an observed server error or claim that a local check is a successful paid API run.
Choose an endpoint before changing model names
| Intended request | Format to evaluate | Reasoning setting |
|---|---|---|
| Text with no tools | Supported text request format | Use a documented effort value |
| Chat Completions function calling | /v1/chat/completions | reasoning_effort: "none" |
| Reasoning with function calls | /v1/responses | reasoning: {"effort": "low"} or another supported value |
| Built-in Responses tools | /v1/responses | Check the selected tool’s current requirements |
Sol and Luna support none, low, medium, high, xhigh and max in the reviewed model documentation. The field nesting differs by endpoint. A top-level reasoning_effort copied into a Responses payload is not the same configuration as reasoning.effort.
Do not infer that every OpenAI-compatible gateway already implements every Responses feature. Check the provider and route separately from the model’s native capability.
Prepare a minimal function-call request
Here is a Responses request body that exposes a read-only status lookup. The function schema uses Responses’ tool format, not the nested Chat Completions form.
{
"model": "gpt-6-sol",
"input": "Look up the status of order EXAMPLE-001.",
"reasoning": {"effort": "low"},
"max_output_tokens": 2048,
"tools": [{
"type": "function",
"name": "lookup_order",
"description": "Read the status of a sample order.",
"parameters": {
"type": "object",
"properties": {"order_id": {"type": "string"}},
"required": ["order_id"],
"additionalProperties": false
},
"strict": true
}]
}
This body defines a tool; it does not implement the lookup or guarantee that the model invokes it. Your application must handle the returned function call, validate its arguments, execute the permitted operation and return the tool result using the documented Responses loop. Use a non-sensitive example dataset before connecting a production service.
For an equivalent Chat Completions request, the tool definition uses a nested function object and the reasoning field is top-level. If it contains function tools, use reasoning_effort: "none". Replacing only the endpoint URL while leaving the old payload unchanged is not a migration.
Remove incompatible sampling parameters
The migration guide says that when reasoning is not none, remove temperature, top_p and top_logprobs. For Chat Completions, also remove logprobs. For Responses, remove message.output_text.logprobs from include.
Look for defaults inserted by your SDK wrapper, not just fields visible in your own source file. A logging middleware or tracing tool can help inspect the final request shape, provided it redacts credentials and sensitive content. Retain the actual server response when diagnosing a failure; do not replace it with a guessed error string from a different model.
Check the payload locally
Download the request checker and example JSON body. Run:
python3 check_request.py responses responses-example.json
The checker catches the specific endpoint, effort and parameter mismatches covered here. It makes no network request and does not certify model access, every schema field, tool behavior, rate limits or a provider’s implementation. Its tests use synthetic payloads, including deliberate invalid cases, rather than paid inference.
For an existing Chat Completions body, save it with secrets removed and use chat as the first argument. Review each diagnostic before sending the request. Do not remove a field blindly if your application relies on its behavior; change the integration deliberately and test the relevant output handling.
Preserve state and billing evidence
A working agent loop needs more than one valid request. Keep the returned tool-call identifier, send the matching result and preserve the conversation items required by the API. Consult the function-calling documentation for the full loop.
If migrating from GPT-5.5 or earlier, the current guide also describes replacing prompt_cache_retention with prompt_cache_options.ttl set to "30m". Do not carry an older cache configuration across solely because the JSON parses. Cache eligibility and billing should be verified independently.
Use the access guide if the issue is availability, and the Sol or Luna pricing guide when interpreting usage. A validated request shape is one checkpoint; the final acceptance check is a correctly handled, authorized task with a traceable response.
Frequently Asked Questions
- Can Sol or Luna use function calls in Chat Completions?
- Yes, with reasoning_effort set to none according to the current model guidance. Use Responses when combining reasoning with function calls.
- Does passing the local checker prove API access?
- No. It checks selected request-shape rules without sending a request or verifying account permissions, billing or model behavior.
- Should I keep temperature when reasoning is enabled?
- The current migration guide says to remove temperature, top_p and top_logprobs when reasoning is not none, with additional endpoint-specific logprobs checks.


