Copy page

Provider implementation standard

Use this standard when creating or materially expanding a provider plugin bundle.

It complements the detailed provider, extension, tool-interop, packaging, and testing guides by defining the minimum portable boundaries expected from a substantial provider implementation.

Documents

• Runtime contract: provider lifecycle, conversion, streaming, native history, cancellation, errors, and redaction.
• Feature ownership: provider versus extension, feature, tool, and application responsibilities.
• Compatible endpoint configuration: shared baseline tags, optional feature gating, inspectable presets, and tests.
• Conformance testing: deterministic, application, local-compatible, and hosted verification.
• Usage, cost, and performance: normalized usage, pricing catalogs, cost-estimation provenance, cached-token estimation, and duration/TPS interoperability.
• Package and documentation: package layout, descriptors, README/docs, tests, and delivery checklist.

Minimum implementation checklist

A substantial provider bundle should provide:

• an explicit provider ID and package;
• ordinary and streaming request support where the API supports streaming;
• core/native conversion and coherent complete native history;
• request-ID cancellation;
• redacted deterministic errors;
• model discovery or an explicit manual-model fallback;
• separate provider extensions for optional provider-specific features;
• normalized usage and performance metadata when token counts are available;
• request-bound tool interop;
• deterministic provider and extension tests;
• application integration;
• local-compatible or hosted verification appropriate to the protocol;
• current package documentation.

Optional provider features are not universal requirements. When implemented, they follow the ownership and verification rules in this standard.