v0.5.2

Pins the tokenizer to the model revision and exports the Inspect provider as a class that can be subclassed. This is a patch release without any new methods.

Changes

• Tokenizer revision: a revision key in hf_model_kwargs now pins the tokenizer to the same Hub commit as the model weights when the tokenizer loads from the model reference (model_name_or_path). The revision applies to the tokenizer loads in SteeringPipeline, PipelineFactory (the shared-base tokenizer used by SteeringEval), and HFBackend. A tokenizer given by tokenizer_name_or_path (a distinct repository) still loads at the repository head, and pipelines without a revision key are unchanged
• Inspect provider: SteeringPipelineModelAPI (evaluation/provider.py) is now exported as a class rather than the wrapper function returned by @modelapi. The class can be subclassed and used with isinstance. The steerability provider is registered through the new factory function steerability_provider, which as_inspect_model uses to construct the provider. The registered provider name and the rendered model name (steerability/<model_name>) are unchanged

Breaking changes

• When hf_model_kwargs contains a revision key and the tokenizer loads from the model reference, the tokenizer (including its chat template) now loads at that revision rather than at the repository head. Prompt rendering and tokenization change when the tokenizer files differ between the two commits
• Constructing SteeringPipelineModelAPI directly no longer attaches Inspect registry info. An Inspect Model built around such an instance has no registry name (str(model) raises ValueError). as_inspect_model is unaffected, and a subclass is registered with Inspect through its own factory function decorated with @modelapi

What's Changed

• Pin the tokenizer to the model revision and export the Inspect provider as a class by @emiehling in #34

Full Changelog: v0.5.1...v0.5.2