* fix(azure_openai): harden streaming, stop semantics, and version gating - gate stream_options by effective api-version (>= 2024-08-01-preview or /openai/v1); tiktoken fallback already covers older endpoints - preflight guard: Responses-routed models (gpt-5*, codex) fail with an actionable message unless the endpoint exposes /responses - Responses API: never send unsupported 'stop'; enforce client-side with literal matching in blocking, streaming, and o1 block-as-stream paths; holdback buffer catches sequences split across deltas; tool-call arguments bypass matching; held-back text flushes before tool output - capture real usage from terminal events (completed/incomplete) instead of estimating; map incomplete -> finish_reason=length; failed/error streams raise instead of reporting success - always close synthetic reasoning blocks as standalone chunks, in both Responses and Chat Completions streaming handlers, including mixed reasoning+tool deltas - tolerate model_extra=None, content=None, and sparse ChoiceDeltaToolCall deltas (index-padded merge, synthetic ids for placeholders) - defensive image token estimation (remote URLs, malformed data URIs) - account tool_calls before list flattening in token counting; include gpt-5 image costs; deduplicate key counting - TTS: real parallel fetch inside workers with proper context/executor lifecycle; remove dead code - redact full request payload from INFO logs; normalize credential handling for None/malformed values; validate api-version shape and compare calendar dates (GA on threshold date satisfies preview minimum) - manifest 0.0.68; 46 new regression tests * refactor(azure_openai): drop redundant str() coercion on openai_api_base Per review feedback: openai_api_base is a required provider-form field, so wrapping it in str() was dead defensiveness. Keep the 'or ""' guard so a null api_base still fails closed in version gating or raises the clear 'API Base URL is required' error, and restore the original credential indexing in _build_client (the value is validated by _to_credential_kwargs one line above). --------- Co-authored-by: hpiclaranet <hpiclaranet@users.noreply.github.com>
Dify Cloud · Self-hosting · Documentation · Enterprise inquiry
Introduction
Dify is an open-source platform for developing LLM-powered AI applications, designed to help developers and businesses efficiently build, deploy, and manage AI-driven solutions. With Dify, users can easily create and test complex AI workflows, integrate a wide range of advanced models and tools, and optimize their performance in real-world applications. The platform offers an intuitive interface, supporting RAG (Retrieval-Augmented Generation) pipelines, intelligent agent capabilities, and robust model management, enabling developers to seamlessly transition from prototype to production.
Dify's models and tools were originally stored in the main Dify repository. However, starting from Dify v1.0.0 (February 2025), all models and tools have been migrated into plugins and are now stored in this repository. All plugins in this repository will be uploaded to the Dify Marketplace, where they will be maintained and updated by the official Dify team. The plugins in the Marketplace are available for all Dify users to explore and use.
Plugin Types
Models
Models transform AI model management in Dify. Now you can configure, update and use models as plugins across chatbots, agents, chatflows and workflows.
Tools
Tools add specialized capabilities to Dify apps. Enhance your agents and workflows with domain-specific features for data analysis, content translation, custom integrations and more.
Agent Strategies
Agent Strategies provide reasoning strategies for the new Agent Nodes in Dify chatflows / workflows, supporting autonomous tool selection and execution for multi-step reasoning. Create custom reasoning strategies like Chain-of-Thoughts, Tree-of-Thoughts, Function call and ReAct to enhance the problem-solving abilities of your chatflows / workflows.
Extensions
Extensions facilitate external integrations through HTTP webhooks. Build custom APIs to handle complex workflows, process data, or connect with external services, making your applications more versatile and powerful.
Update
In the future, all new official plugins developed by Dify will be updated and maintained in this repository.
Dependency Management
Python plugins should declare dependencies in pyproject.toml and commit the generated uv.lock. After changing dependencies, run uv lock and commit both files. Use uv sync --frozen from the plugin directory to reproduce the locked environment.
During the migration from requirements.txt, legacy plugins without uv.lock may keep using requirements.txt. CI/CD uses uv.lock first and falls back to requirements.txt only when no lock file is present.
Security disclosure
To protect your privacy, please avoid posting security issues on GitHub. Instead, send your questions to security@dify.ai and we will provide you with a more detailed answer.
