ToranaSupport matrix · formats and harnesses
What works with Torana.
Torana runs request and response plugins on recognized model-inference endpoints. Choose a native route for the upstream’s own API, or an opt-in bridge to translate a different client API. “Preserved” in the native matrix below means executable fixtures cover the wire behavior; it does not claim that every model or account enables the provider feature.
One shared format for plugins
Torana converts supported provider requests and responses into a shared format, so plugins can work with messages, tools, and usage without parsing each provider’s JSON separately. Technical references call this an intermediate representation, or IR.
This makes shared plugin logic reusable; it does not make every provider feature interchangeable. On a native route your harness speaks the upstream’s API. With a bridge it speaks the configured bridge.client contract, while Torana translates supported content to bridge.upstream. A plugin may still depend on particular fields or capabilities.
Native provider formats
This table applies to routes without a configured bridge. Native feature preservation is broader than the translation surface.
| Format | Inference endpoints | Streaming | Tools | Prompt-cache behavior | Known boundary |
|---|---|---|---|---|---|
| OpenAI | POST …/chat/completionsPOST …/responses | SSE | Preserved and mutable under explicit grants | prompt_cache_key, prompt_cache_retention, and usage preserved; Responses compaction is opt-in | Provider-owned history behind previous_response_id is not rewritten |
| Anthropic | POST …/messages | SSE | Structured use/results and signatures preserved | Ordered cache_control breakpoints preserved | Both string and block-array system prompts are accepted |
| Gemini / Vertex AI | POST …:generateContentPOST …:streamGenerateContent | SSE | Function calls/results, metadata, and signatures preserved | cachedContent references and usage preserved; Torana does not manage cache resources | Caller-supplied API key or bearer auth; ADC/service-account minting is not built in |
| Gemini Code Assist | POST …:generateContentPOST …:streamGenerateContent | SSE | Function calls/results and signed parts preserved | Provider cache references and usage preserved | Clients without a base-URL setting require Torana’s optional, explicitly configured MITM ingress |
Opt-in protocol bridges
No plugin is required. Configure the client and upstream explicitly using openai-chat, openai-responses, anthropic, gemini, or gemini-codeassist. Provider format describes the upstream family. Cross-family bridges require explicit upstream authentication; caller credentials are not forwarded across families.
Automated mock-HTTP tests cover all 20 cross-contract directions for common text/function-tool loops and JSON/SSE responses. Image inputs and structured-output constraints require a representable mapping and a capable model. This does not establish compatibility with every live harness or backend.
Provider-specific reasoning/signatures, server-native tools, cache breakpoints, opaque continuation items, previous_response_id, and storage/background execution are not portable. Unsupported request semantics return 400 before an upstream call. Non-portable response content produces a 502 or terminates an already-started stream without a success marker.
Set up a bridge with an Anthropic-client/local-OpenAI example. The complete translation reference ↗ covers the finer boundaries.
Selective interception
On native routes, model-list, token-counting, account, quota, status, telemetry, update, MCP, and unknown auxiliary paths pass through without request or response plugins. Real-proxy tests cover that pass-through for all four native formats, including method, path, query, body, permitted headers, upstream status, and response bytes.
Under any configured bridge, model discovery, token-counting, files, batch APIs, response retrieval, and other auxiliary APIs are not emulated or forwarded; they return 400. This includes bridges whose client and upstream contracts match. Changing a base URL alone does not make a harness that requires these APIs compatible.
Coding harnesses
Bring the harness you already use: Claude Code, Codex, pi, oh-my-pi, or OpenCode. Our October 3 walkthrough checked real file reads, usage logging, and recoverable PII-guard responses in all five. Claude and Codex kept their existing logins; pi, oh-my-pi, and OpenCode used a DeepSeek API key. Pick your recipe in the harness guide and try it with your own project. Antigravity also has a separately verified setup.
For Codex response plugins, choose HTTP/SSE with supports_websockets = false: WebSocket connections pass through as opaque streams, outside the response-plugin pipeline. For Antigravity, follow the local TLS setup and choose your tool permissions; the verified headless run used explicit auto-approval. The guide includes tested versions and setup details.
The table below maps native routes to their automated API coverage. Connecting a different kind of backend? Start with the bridge guide.
| Harness path | Torana format | Automated contract |
|---|---|---|
Claude Code via ANTHROPIC_BASE_URL | Anthropic Messages | System prompts, streaming tool use/results, cache markers, signatures, and auxiliary pass-through |
| Codex custom provider | OpenAI Responses | Responses layout, opaque input items, streaming tools, and model-list pass-through |
| pi, oh-my-pi, OpenCode custom provider | OpenAI Chat Completions in the live checks | Tool calls/results and usage; other providers depend on the selected wire format |
| Aider base URL | OpenAI or Anthropic | The selected provider wire has automated coverage; not part of the five-harness live walkthrough |
| Antigravity / Code Assist | Gemini Code Assist | Wrapper data, signed parts, cache facts, stream framing, and auxiliary pass-through |
About the live checks and API coverage
The dated harness results record the versions, models, authentication routes, resume checks, and workflows covered. Cache hits were observed in the five-harness walkthrough; that does not establish perfect prefix preservation for every workflow. These checks do not cover every tool, login refresh, or provider account.
Automated API fixtures exercise protocol behavior, including the 20 bridge directions. They are separate from credentialed harness checks, not evidence that every real harness/backend combination has been run.
Have a favorite harness or a workflow you want to bring to Torana? Share your setup or the first rough edge. Working recipes, bug reports, and small plugins all help shape what comes next.
Plugin SDKs
SDK v0.5.1 implements ABI major 1, contract revision 1. The SDK package version, plugin ABI, and Edge binary release are separate version numbers. Start with the plugin-authoring guide for a project pinned to the host’s SDK.
| Go | ABI v1 SDK, helpers, native test harness, maintained plugin examples, and host conformance. Generated projects pin the Go module to v0.5.1. |
|---|---|
| Rust | ABI v1 bindings, typed results, and safe wrappers. The logger and all-hooks guests run through the shared host conformance harness. Generated projects pin the matching exact crate version and retain a reviewed Cargo.lock. |
Want to build an SDK for another language?
Go and Rust are the ready-to-use SDKs today. For TypeScript, AssemblyScript, or another WASI language, a new SDK needs to implement Torana’s protobuf ABI, allocator, framed host calls, and hook contract, then run a guest through host conformance. Compiling to WASM is one part of that work.
Start with the plugin ABI guide and open an SDK issue to discuss your language and approach.
How to read this matrix
Coverage is endpoint-specific: matching a provider name alone is not enough. Use the format and harness rows above to choose your route and distinguish automated wire tests from credentialed client checks.
Implementation evidence: harness boundary ↗ · prompt caching ↗ · benchmarks ↗