What happened
While building a TEE-based governance agent for the MetaMask Smart Accounts Kit × 1Shot API × Venice AI Dev Cook-Off, we went looking for the "TEE models" the docs and product pages describe. We expected ids like tee-* — but nothing in GET /models matches that. The actual TEE-attestation models are named with an e2ee- prefix (e.g. e2ee-gpt-oss-120b-p), and the only reliable way we found to discover them is to filter /models by the capability flag:
model_spec.capabilities.supportsTeeAttestation === true
That mapping ("TEE" in prose ⇄ e2ee-* ids + supportsTeeAttestation flag) doesn't appear anywhere we could find in the docs, so we lost a stretch of time hardcoding guessed ids before reading raw /models output.
Suggestion
- Wherever TEE inference is described, document that the model ids carry the
e2ee- prefix (and briefly why, since "E2EE" vs "TEE" naming is itself confusing).
- Document capability-based discovery as the recommended pattern — a 5-line snippet filtering
/models on supportsTeeAttestation would let clients auto-resolve a TEE model instead of pinning ids that may rotate.
- Bonus: the
/tee/attestation endpoint docs could cross-link to that discovery snippet, since attestation requests need exactly these model ids.
Our workaround (auto-resolve by capability, fall back from a configured id) is here if useful: https://github.com/beautifulrem/regent (packages/shared/src/venice.ts, resolveTeeModel; live demo https://mandate-app-murex.vercel.app).
What happened
While building a TEE-based governance agent for the MetaMask Smart Accounts Kit × 1Shot API × Venice AI Dev Cook-Off, we went looking for the "TEE models" the docs and product pages describe. We expected ids like
tee-*— but nothing inGET /modelsmatches that. The actual TEE-attestation models are named with ane2ee-prefix (e.g.e2ee-gpt-oss-120b-p), and the only reliable way we found to discover them is to filter/modelsby the capability flag:That mapping ("TEE" in prose ⇄
e2ee-*ids +supportsTeeAttestationflag) doesn't appear anywhere we could find in the docs, so we lost a stretch of time hardcoding guessed ids before reading raw/modelsoutput.Suggestion
e2ee-prefix (and briefly why, since "E2EE" vs "TEE" naming is itself confusing)./modelsonsupportsTeeAttestationwould let clients auto-resolve a TEE model instead of pinning ids that may rotate./tee/attestationendpoint docs could cross-link to that discovery snippet, since attestation requests need exactly these model ids.Our workaround (auto-resolve by capability, fall back from a configured id) is here if useful: https://github.com/beautifulrem/regent (packages/shared/src/venice.ts,
resolveTeeModel; live demo https://mandate-app-murex.vercel.app).