AI Engineer Portal

Your personal operating system for career transition.

Private mode

Exercise

Build a Pydantic model hierarchy for multi-provider LLM responses

Build a Pydantic Model Hierarchy for Multi-Provider LLM Responses

Different LLM providers return fundamentally different response shapes. OpenAI wraps content in choices[0].message.content, Anthropic wraps it in content[0].text, and a local Ollama server returns {"response": "..."}. Without a shared internal type, your application code ends up scattered with if provider == "openai" conditionals.

What to build

Design a Pydantic model hierarchy that:

Defines provider-specific models — OpenAIResponse, AnthropicResponse, and LocalResponse, each with the fields that match that provider's real API shape.
Uses discriminated unions — add a provider: Literal[...] field to each model so Pydantic can route validation automatically.
Exposes a shared interface — each model must implement a .normalized() method that returns a NormalizedLLMResponse with fields: request_id, text, model, input_tokens, output_tokens.
Validates via a factory function — parse_provider_response(raw: dict, provider: str) -> NormalizedLLMResponse that accepts raw JSON and the provider name, validates the correct model, and returns the normalized form.
Handles validation failures gracefully — if the raw dict does not match the expected shape, raise a descriptive ValueError.

Why this matters

Every AI backend that touches more than one provider needs this pattern. Without it, normalization logic leaks into application code, provider changes break multiple callsites, and testing requires mocking raw provider SDKs. A clean model hierarchy confines the mess to one place.

Constraints

Use Pydantic v2 (from pydantic import BaseModel).
Do not use Any in model fields — be explicit about types.
The parse_provider_response function should work for all three providers from a single entry point.

Python Ai / medium / Step 1 of 6

Practice stage

General drill

Hint

Keep the solution explicit and reviewable.

Next drill

Implement async batch processing for LLM calls

Success criteria

Make the solution explicit, debuggable, and easy to explain.

Review checklist

Review where the boundary is, what gets validated, and what would be hard to debug later.

from __future__ import annotations
from typing import Literal, Union
from pydantic import BaseModel

class NormalizedLLMResponse(BaseModel):
    request_id: str
    text: str
    model: str
    input_tokens: int
    output_tokens: int

class OpenAIResponse(BaseModel):
    provider: Literal["openai"] = "openai"
    # TODO: add fields matching OpenAI's chat completion response shape
    # id, choices (list with message.content), model, usage (prompt_tokens, completion_tokens)

def normalized(self) -> NormalizedLLMResponse:
        raise NotImplementedError

class AnthropicResponse(BaseModel):
    provider: Literal["anthropic"] = "anthropic"
    # TODO: add fields matching Anthropic's response shape
    # id, content (list with text field), model, usage (input_tokens, output_tokens)

def normalized(self) -> NormalizedLLMResponse:
        raise NotImplementedError

class LocalResponse(BaseModel):
    provider: Literal["local"] = "local"
    # TODO: add fields for a local model response
    # model, response (text string), prompt_eval_count, eval_count

def normalized(self) -> NormalizedLLMResponse:
        raise NotImplementedError

ProviderResponse = Union[OpenAIResponse, AnthropicResponse, LocalResponse]

def parse_provider_response(raw: dict, provider: str) -> NormalizedLLMResponse:
    # TODO: inject provider key, validate correct model, return normalized form
    raise NotImplementedError

Practice

Generate a variation

Generate a new exercise variation to deepen understanding or practice a related concept.

Attempt history

Recent submissions

Before you submit, decide what a strong answer should make obvious to the reviewer.

No attempts yet.