1.20.0

Added

• Local file sending via send_image, send_video and send_audio: the tools now accept either an http(s) URL (behaviour unchanged) or a path to a file on disk — no more spinning up a throwaway HTTP server just to hand a locally generated file to the chat. Local-path access is gated by FILESYSTEM_ACCESS exactly like the agent's file tools, and nonexistent paths or directories are rejected with a clear, actionable error. The parameter names keep their *_url names (they are part of the model-facing tool contract) — only the schema descriptions changed to advertise both forms. On the Telegram and Scheduler runtimes, images from disk are delivered through the same size-partitioned buffer pipeline as generated images (photo vs document), while audio/video are streamed by python-telegram-bot directly from the path; audio URLs keep their download-then-attach behaviour. If the image media-group upload fails, the plain-text fallback reports only the file's base name for local files, so no absolute filesystem path can leak into the chat history or the model's context. (This fix also repairs the URL fallback on the Telegram runtime, which previously crashed with a duplicate-keyword error instead of delivering the fallback text.)
• Image-to-image support in the generate_image tool: the tool now accepts optional reference_file_ids (Telegram file IDs of previously uploaded images) and/or reference_paths (local filesystem paths; requires filesystem_access to be enabled) and passes the resolved reference images to the selected image model. Provider and model capability gating prevents calls to models without image input support: supported out of the box for Gemini Nano Banana content-creation models (gemini-*-image, via inline prompt parts) and OpenAI gpt-image-* models (via the Images Edit API), while imagen-* / dall-e-* models and providers without image input reject the call with a clear error. Reference images are limited to PNG, JPEG and WebP, at most 10 images, 10 MB each; calls without reference input behave exactly as before.
• Provider failover engine (auto ladder, manual chains, 20-minute cooldown store): when an LLM request fails on rate limits, server errors, timeouts or network failures (context overflow and moderation errors are deliberately excluded — they have their own recovery paths), the request is retried behind a fallback policy resolved per role (master / subagent). AUTO (default, zero config): the failed provider goes on a 20-minute cooldown (the only persistent state — Redis when configured, in-memory otherwise; it affects only auto-selection, never manual choices), then the same model is retried on another provider (exact-name match against the in-memory model registry), then the next provider's default model, then an honest failure — no model mixing, no revisiting already-tried pairs, no cross-mode cascades. The primary is always attempted first and the ladder — including model enumeration and cooldown-store access — is built lazily only after the primary fails, so the happy path keeps zero extra latency. MANUAL: an ordered chain of provider/model pairs fully replaces the ladder for that role, head of the chain is the primary, and the cooldown never blocks it (explicit user choice). DISABLED: a single attempt, honest failure.
• Failover chain configuration with non-fatal validation: two new settings, FAILOVER_CHAIN_MASTER (main chat) and FAILOVER_CHAIN_SUBAGENT (sub-agent requests), each accepting auto (default), disabled, or an ordered comma-separated list of provider/model pairs split on the first slash (model names may contain slashes, e.g. google/gemini-3.5-flash-lite). Validation is non-fatal by design: empty, missing-slash, empty-part and duplicate entries are warned about and skipped — a malformed chain never prevents Chibi from starting. Policies are resolved once per process and memoized; the resolved policy (policy cache, cooldown store, model registry) can be reset programmatically for tests and future runtime overrides.
• In-chat warnings on every fallback attempt: each transition to a fallback (auto ladder or manual chain alike, never the primary attempt) announces the trigger (rate limit / server error / timeout / network) and the pair about to be attempted — as a chat warning for master requests and a log warning for sub-agent requests. The final failure, when every step of the chain fails, is always reported honestly with the last provider error; hook failures are logged and swallowed so a notification can neither block nor break the fallback walk.
• Text-to-video generation via three new providers: Alibaba (Wan, wan2.6-t2v — async AioVideoSynthesis submit/poll/download), ZhipuAI (cogvideox-3 on the same z.ai base URL and API key as chat/image) and MiniMax (Hailuo H3/H3-Max via the V2 API). Polling happens inside the provider (get_videos, bounded 15 s interval / 480 s timeout) and always returns downloaded MP4 bytes — provider URLs expire after 1–24 h. Providers declare their video models and are video_generation_ready when a key is configured.
• New generate_video and get_available_video_generation_models tools: the model picks a provider (or uses the user's active video provider fallback, mirroring the image flow), generation runs in the background (1–6 min), and the finished clip is delivered to Telegram via send_video with a cover thumbnail downscaled to the Bot API constraints (JPEG < 200 kB, ≤ 320 px). Clips larger than ~48 MB are delivered as documents. Tools are registered only when at least one video-capable provider key is configured (respecting TOOLS_WHITELIST and PUBLIC_MODE semantics of the other tools).
• Video generation limits, 1:1 with images: VIDEO_GENERATIONS_LIMIT monthly cap, VIDEO_GENERATIONS_WHITELIST allowlist, User.videos history with backward-compatible storage defaults, per-thread and per-user active video provider/model selection (/video_models-style plumbing), and e2e-style flow tests covering delivery, the size guard and the limit-exceeded path.
• Docs: video generation providers documented in README and all translated READMEs.
• Header/secret authentication for SSE MCP servers and a new REST transport: initialize_sse_mcp_server now accepts optional headers (plain HTTP headers sent with every request, e.g. Authorization) and secret_envs (secret entries resolved from the process environment with fallback to the env file), both merged into the request by a shared auth-header helper with a documented precedence. A new initialize_rest_mcp_server tool connects to MCP servers over plain JSON-RPC HTTP POST (the SDK's stateless streamable-HTTP transport), for JSON-RPC endpoints that support neither SSE nor session negotiation; it is gated by the new enable_mcp_rest setting (ENABLE_MCP_REST, default false, documented in the Docker Hub README and the generated sample config), and deinitialize_mcp_server is registered whenever it is enabled. The mcp SDK was bumped to 2.3.0 (with an explicit httpx2 dependency and regenerated lock/exports), covered by new unit tests, a dedicated SSE-auth module and an offline mock-transport regression test for stateless servers.