Skip to content

OpenAI backend hardcodes temperature=0, causing semantic extraction failure on models that only support default temperature #1191

Description

@aziaq

Problem

Graphify semantic extraction fails with some OpenAI models because the OpenAI backend sends temperature=0.

The model/API returns:

Unsupported value: 'temperature' does not support 0 with this model. Only the default (1) value is supported.

Result:

WARNING: 59/59 semantic chunk(s) failed
error: all semantic chunks failed for backend 'openai'

Impact

Graphify still creates a structural/AST graph, but the semantic layer is missing.

This makes natural-language graph queries weak because concept nodes and semantic relationships are not generated. In my case, query results fell back to lexical/structural matches instead of repository architecture relationships.

Environment

graphifyy: 0.8.35
install: uv tool install graphifyy
backend: openai
command: graphify extract . --backend openai --no-cluster --max-concurrency 1 --token-budget 1000 --api-timeout 900

Root Cause

In graphify/llm.py, the OpenAI backend config hardcodes:

"temperature": 0,

The call path appears to omit temperature only when it is None:

if temperature is not None:
kwargs["temperature"] = temperature

So the OpenAI backend currently always sends temperature=0.

Suggested Fix

Change the OpenAI backend config from:

"temperature": 0,

to:

"temperature": None,

or make temperature configurable per backend/model.

Example minimal patch:

**--- graphify/llm.py
+++ graphify/llm.py
@@

  •    "temperature": 0,
    
  •    "temperature": None,**
    

Why this works

If temperature=None, Graphify omits the field and the selected OpenAI model uses its default temperature.

This matches the behavior already used by backends that do not force temperature.

Expected Behavior

Graphify should complete semantic extraction instead of failing every chunk when a model rejects temperature=0.

Expected output:

**semantic extraction on N files via openai...
chunk 1/N done

chunk N/N done
wrote graphify-out/graph.json**

Actual Behavior

[graphify] chunk 1/59 failed: Error code: 400 - Unsupported value: 'temperature' does not support 0 with this model. Only the default (1) value is supported.
...
[graphify] WARNING: 59/59 semantic chunk(s) failed
[graphify extract] error: all semantic chunks failed for backend 'openai'

Request

Please consider either:

  1. Omitting temperature for the OpenAI backend by default, or
  2. Adding a CLI/env option such as GRAPHIFY_OPENAI_TEMPERATURE, or
  3. Detecting unsupported temperature errors and retrying without the temperature field.

This would allow Graphify to work with newer OpenAI models that only support their default temperature value.

Additional Test Result After Local Temperature Patch

Additional Test Result After Local Temperature Patch

I tested a local patch that changes the OpenAI backend temperature from 0 to None.

Result:

  • Temperature error disappeared.
  • OpenAI semantic extraction completed.
  • Graph files were generated:
    • graphify-out/graph.json
    • graphify-out/GRAPH_REPORT.md
    • graphify-out/graph.html
  • Noise check passed.

However, query quality was still not reliable enough for my automated assistant context use case.

Observed results:

  • A freshness/state query improved and returned relevant backend state-computation files.
  • A correlation query still routed mostly to database documentation, seed/schema-related files, and frontend API-client files.
  • An incident/WebSocket query routed mainly to a frontend API-client file.
  • A sensor-ingest query routed into frontend UI/tests and database documentation instead of the expected backend ingest path.

So the patch fixes the temperature failure and allows semantic extraction to proceed, but it does not fully solve query quality for architecture-level assistant use in a large mixed repository.

Conclusion:

  • Temperature handling is a real compatibility bug.
  • Fixing it improves extraction.
  • Graphify query/ranking may also need stronger file-path anchoring or ranking behavior for code-architecture use cases in large mixed repositories.
  • In my repository, Graphify is useful as an assistive visual/manual map, but I would not yet rely on free-text query results as an automated authority without additional query/ranking improvements.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions