katanemo/plano

First, thank you to the Plano maintainers and contributors for building and open-sourcing this project. The existing unified endpoint and routing design is already very useful in practice. Summary According to Gemini API version docs, the API has both v1 (stable) and v1beta (early features), and Gemini SDKs default to v1beta unless api_version is explicitly changed. To improve drop-in compatibility, Plano should perhaps support these Gemini v1beta routes: POST /v1beta/models/{model}:generateContent POST /v1beta/models/{model}:streamGenerateContent These requests should be translated into Plano’s existing routing/provider pipeline so existing Gemini clients can use Plano with little to no request-format changes. Current behavior A request like: POST /v1beta/models/gemini-2.5-flash:generateContent returns 404 Not Found from Plano 0.4.9, even when Gemini model providers are configured. Expected behavior When a Gemini provider is configured, Plano should accept the above v1beta endpoin

Summary Plano's WASM filters hardcode 30-second timeouts on all outbound HTTP calls, making Plano unusable for agentic workloads where LLM calls with tool use regularly exceed 30 seconds — despite Plano's docs explicitly supporting agent architectures. Root Cause Four constants in crates/common/src/consts.rs: pub const ARCH_FC_REQUEST_TIMEOUT_MS: u64 = 30000; pub const DEFAULT_TARGET_REQUEST_TIMEOUT_MS: u64 = 30000; pub const API_REQUEST_TIMEOUT_MS: u64 = 30000; pub const MODEL_SERVER_REQUEST_TIMEOUT_MS: u64 = 30000; These are used in two ways: Request header — stream_context.rs and http_context.rs set x-envoy-upstream-rq-timeout-ms: 30000 on outbound calls, overriding Envoy's route-level timeout: 300s. dispatch_http_call — the WASM dispatch_http_call function is called with a Duration based on these constants, hardcoding the timeout in the WASM binary itself. The YAML listener timeout field only affects the inbound Envoy route timeout and has no effect on the WASM filter's