A zero-dependency, high-performance Go proxy server that introspects any Gradio chat space (such as Hugging Face Spaces or custom deployments) and exposes a standards-compliant OpenAI `/v1/chat/completions` and `/v1/models` HTTP API.
- Automatically interrogates `/gradio_api/info`, `/config`, and Hugging Face metadata without endpoint-specific hardcoding.
- Detects Gradio runtime versions across v3, v4, v5, and v6.
- Classifies application architecture into `ChatInterface`, `Blocks (Chat)`, `Blocks (Multimodal Chat)`, `Interface`, and `Generic`.
- Disambiguation scoring engine evaluates candidate endpoints, filtering out UI resets, clears, retries, likes, and utility triggers to pinpoint primary conversational completion functions.
- Correlates semantic parameter names from `/gradio_api/info` with component IDs from `/config` to reconstruct parameter mappings even when component labels are obfuscated.
- **Dual protocol support with auto-fallback**:
- Supports modern Gradio 4/5/6 `/call` SSE protocol with persistent session hashes.
- Supports legacy Gradio 3 `/run/predict` and `/api/predict` direct execution protocol.
- Instant zero-latency fallback from `/call` to `/run/predict` upon HTTP 404 or 405 status codes.
- Automatically formats conversation history into structured inputs when the space supports them.
- Transparently composes multi-turn dialogue (`System`, `User`, `Assistant`) into single prompt inputs when the space only accepts a single message textbox.
- Automatically pads hidden/State inputs (e.g. Gradio State components) to prevent backend argument count mismatches.
- Resilient backoff retry mechanism (1s, 1s, 2s, 3s, 5s) for transient network hiccups with immediate break on 404/405 errors.
## Heuristic discovery engine
The gateway implements an autonomous heuristic engine that discovers and configures the optimal completion path for any target Gradio space at startup.
### Space introspection and version detection
Upon initialization, `gr2gw` inspects the space metadata:
1. Queries `/gradio_api/info` and `/config` endpoints.
2. Extracts the Gradio runtime version (v3, v4, v5, or v6).
3. Detects API routing prefixes (e.g. `/gradio_api` on modern versions, or root on Gradio 3).
### UI flavor classification
The engine classifies the application structure into architectural flavors:
- **`ChatInterface`**: Standard Gradio chat interfaces equipped with chatbot, textbox, and optional additional inputs.
- **`Generic`**: Spaces with custom or unclassified component topologies.
### Candidate endpoint scoring
Gradio spaces frequently expose dozens of internal endpoints for UI actions (e.g. clearing text, retrying responses, voting/liking, adjusting sliders). The scoring algorithm identifies the true conversational endpoint by:
- Penalizing non-conversational triggers (e.g. `-600` for clear/reset/undo/retry/like endpoints).
- Rewarding chat semantics (`+150` for `/chat`, `/predict`, `/generate`, `/respond`).
- Rewarding message inputs (`+120` for `Textbox` or `MultimodalTextbox`).
- Rewarding chat history slots (`+80` for `Chatbot` or `State` components).
- Rewarding generator and streaming dependencies (`+50`).
### Dual protocol execution and auto-fallback
- **`call` protocol**: Modern Gradio 4/5/6 execution via `POST /call/{endpoint}` returning an event ID, followed by `GET /call/{endpoint}/{event_id}` SSE streaming.
- **`predict` protocol**: Gradio 3 and legacy execution via direct `POST /run/predict` or `POST /api/predict`.
- **Runtime failover**: If a space returns HTTP 404 or 405 when calling the modern protocol, the gateway breaks immediately from the retry loop and falls back to `/run/predict`.
### Tool calling support modes
The gateway evaluates available input components to determine how tool schemas and function calls should be delivered:
- **`native_slot`**: The space provides a dedicated parameter slot for tool definitions (e.g. `functions_json_str` on Hunyuan 3). Function definitions are passed cleanly without prompt alteration.
- **`prompt_augmented_system`**: The space provides a separate `system_prompt` input slot. Tool definitions and invocation schemas are injected directly into the system prompt.
- **`prompt_augmented_first_turn`**: The space accepts chat history pairs but lacks a dedicated system prompt slot. Tool definitions are prepended to the user prompt on the first dialogue turn.
- **`prompt_augmented_single_prompt`**: The space accepts only a single textbox input. Full multi-turn dialogue, tool definitions, and system guidance are synthesized into a single cohesive prompt.
### Startup resolution diagnostics
Whenever the gateway starts or inspects a new space, it prints the complete resolution picture: