Summary
Would you consider replacing the pinned unclecode-litellm==1.81.13 dependency with a recent, maintained, security-reviewed version of upstream litellm, and validating the compatibility of LLMExtractionStrategy with newer reasoning models (including GPT-5.6 deployments such as Luna and Sol)?
Thank you for maintaining Crawl4AI. This request is motivated by practical issues with LLM-based extraction in enterprise RAG pipelines.
Current state
The current pyproject.toml on main still pins:
"unclecode-litellm==1.81.13",
That fork was introduced during the upstream LiteLLM PyPI supply-chain incident. The official LiteLLM project has since continued adding support for newer models and their API requirements, whereas the pinned fork remains on the earlier codebase.
Why this matters
In our usage, LLMExtractionStrategy performs noticeably worse with newer GPT-5.6 Luna/Sol deployments than with GPT-4.1 under comparable extraction tasks. We have not isolated the root cause, so we are not claiming that the dependency pin alone is responsible. However, the old integration layer may not fully recognize or correctly handle newer model capabilities and parameters.
Areas worth investigating:
- Model identification and provider routing for newer OpenAI / Azure OpenAI deployments, including deployments behind enterprise API gateways.
- Chat Completions vs. Responses API handling, where applicable.
- Reasoning-specific output/token parameters (e.g.,
max_completion_tokens), unsupported sampling arguments, and completion truncation.
- Normalization of response content, token usage, and structured JSON extraction.
- Silent dropping of unsupported arguments via
litellm.drop_params = True.
Crawl4AI's perform_completion_with_backoff() / aperform_completion_with_backoff() set temperature=0.01 by default and pass responses into an extraction pipeline that expects response.choices[0].message.content. These behaviors are reasonable compatibility checkpoints when upgrading.
Requested changes
- Replace
unclecode-litellm==1.81.13 with an appropriately pinned/restricted current stable upstream LiteLLM release, after security review (not an unbounded latest-at-runtime install).
- Ensure installations cannot leave both distributions writing into the same
site-packages/litellm module.
- Add basic regression coverage for
LLMExtractionStrategy using GPT-4.1 as a baseline and newer GPT-5.x reasoning models, including Azure OpenAI deployments where feasible.
- Check the handling of reasoning parameters, nonempty extraction output, JSON/schema parsing, and
finish_reason / usage metadata.
- Document the supported model/API combinations and any recommended settings for GPT-5.x.
Related issue
A straightforward upgrade path would be very helpful for enterprise Docker/OpenShift deployments, where we need reproducible builds and cannot safely overlay different LiteLLM distributions with ad-hoc pip install commands.
Thanks again!
Summary
Would you consider replacing the pinned
unclecode-litellm==1.81.13dependency with a recent, maintained, security-reviewed version of upstreamlitellm, and validating the compatibility ofLLMExtractionStrategywith newer reasoning models (including GPT-5.6 deployments such as Luna and Sol)?Thank you for maintaining Crawl4AI. This request is motivated by practical issues with LLM-based extraction in enterprise RAG pipelines.
Current state
The current
pyproject.tomlonmainstill pins:"unclecode-litellm==1.81.13",That fork was introduced during the upstream LiteLLM PyPI supply-chain incident. The official LiteLLM project has since continued adding support for newer models and their API requirements, whereas the pinned fork remains on the earlier codebase.
Why this matters
In our usage,
LLMExtractionStrategyperforms noticeably worse with newer GPT-5.6 Luna/Sol deployments than with GPT-4.1 under comparable extraction tasks. We have not isolated the root cause, so we are not claiming that the dependency pin alone is responsible. However, the old integration layer may not fully recognize or correctly handle newer model capabilities and parameters.Areas worth investigating:
max_completion_tokens), unsupported sampling arguments, and completion truncation.litellm.drop_params = True.Crawl4AI's
perform_completion_with_backoff()/aperform_completion_with_backoff()settemperature=0.01by default and pass responses into an extraction pipeline that expectsresponse.choices[0].message.content. These behaviors are reasonable compatibility checkpoints when upgrading.Requested changes
unclecode-litellm==1.81.13with an appropriately pinned/restricted current stable upstream LiteLLM release, after security review (not an unbounded latest-at-runtime install).site-packages/litellmmodule.LLMExtractionStrategyusing GPT-4.1 as a baseline and newer GPT-5.x reasoning models, including Azure OpenAI deployments where feasible.finish_reason/ usage metadata.Related issue
A straightforward upgrade path would be very helpful for enterprise Docker/OpenShift deployments, where we need reproducible builds and cannot safely overlay different LiteLLM distributions with ad-hoc
pip installcommands.Thanks again!