Not as "drop-in" yet because the "guardrail client" returns `GuardrailsResponse` instead of standard OpenAI response objects

[fletchersarip93]

Hello OpenAI team,

This is a great framework! However, it seems it cannot yet be used as drop-in replacement of the OpenAI client. The main reason is because GuardrailsAsyncOpenAI returns GuardrailsResponse object instead of the standard OpenAI response objects.

For example, I tried to integrate this with Pydantic AI simply by replacing the OpenAI client part (doing it as shown in this doc). But then, when I send a query, I got the error below, which is mainly because Pydantic AI expects a standard OpenAI response object but in reality we got the GuardrailsResponse object instead.

  File "/Users/fsarip/workspace/algo_raya/.venv/lib/python3.12/site-packages/pydantic_ai/models/openai.py", line 875, in request
    return self._process_response(response)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/fsarip/workspace/algo_raya/.venv/lib/python3.12/site-packages/pydantic_ai/models/openai.py", line 894, in _process_response
    timestamp = number_to_datetime(response.created_at)
                                   ^^^^^^^^^^^^^^^^^^^
AttributeError: 'GuardrailsResponse' object has no attribute 'created_at'

Ideally, if we want this "guardrail client" to be a "drop-in replacement", it's better if the GuardrailsAsyncOpenAI (and its friends) return a standard OpenAI response objects instead of the special GuardrailsResponse object, to respect the function signature defined by OpenAI client (and in turn this can seamlessly be integrated with any other agent frameworks).

Would like to discuss on how we can move forward with this.

[fletchersarip93]

I've created a draft PR, you can check specifically on this change which illustrates what I'm thinking we can do.