Google.generativeai vs python-genai

Gemini API
,
1

I see google has new API. GenAI (from google import genai)
I am not sure, Is the GenAI will be replace google.generativeai or they will maintain both?

2

Welcome to the forums!

My understanding is that the new libraries will replace the previous ones. The old ones should continue to work for basic conversational operations, but new features will only be in the new library.

3

Hi OP,

Architectural Differences:

  • google.generativeai - Low-Level API:

    • Direct Model Access: This library provides a relatively direct mapping to the underlying Google generative model APIs. It exposes concepts like GenerationConfig, SafetySettings, and different model variants in a fairly verbose way.

    • Fine-grained Control: You have control over nearly every aspect of model interaction, including sampling parameters, safety filters, specific endpoint calls, and input/output data structure definitions.

    • Object-Oriented Style: It emphasizes object creation (e.g., creating a generativeai.GenerativeModel) before use, following a more typical OOP pattern.

    • Protobuf Reflection: It often uses and relies on Google’s Protocol Buffers internally, and sometimes the details are leaked out into the client-facing APIs (you often deal with complex Message and enum type constructs directly).

    • Granular Error Handling: You get access to specific API error codes, enabling more targeted error handling based on Google’s backend responses.

  • genai - High-Level Facade / Abstraction:

    • Simplified Workflow: genai is designed to offer a simpler programming model. The aim is to reduce the verbosity required to achieve basic functionalities. The interaction looks more functional.

    • Implicit Defaults: The API makes more reasonable assumptions for typical use cases (e.g. it selects safe default settings, less to do before using the models). The lower-level defaults from google.generativeai are used if defaults aren’t given.

    • Higher Level of Abstraction: Concepts from the original library are simplified, reducing user interaction and configuration. Things like input pre-processing and output post-processing might happen implicitly behind the scenes. The focus is less on directly configuring the backend request than to define the use case.

    • Model Object Selection/Loading: Using the name string makes genai load and configure models in the background for a user; behind the scene there is an abstraction layer that decouples model version details.

    • Internal Library Delegation: genai relies heavily on the google.generativeai library beneath the surface. It acts as a facade, delegating many underlying API calls but offering an ergonomic interface. It also wraps some complex asynchronous operations and presents more Python-idiomatic API structures and function parameters (it hides Google-API related parameter style and types).

    • Abstraction Layer Focus: Instead of managing the entire API stack of Google generative AI from ground up, you focus your application logic and code for the use-case, not the plumbing to the LLM API, using the same simple API abstraction for all model types and interaction techniques (from image/video understanding, to text generations to function call implementations, and chatbot applications).

    • Emphasis on Usability and Rapid Development: It prioritizes getting things done faster, at the expense of sacrificing precise control over some underlying mechanisms. It reduces the number of API concepts one needs to grasp to start with the models, increasing user ramp up efficiency.

    • Ongoing Development: A crucial difference is that the genai layer is relatively nascent and is undergoing active development (as you can tell by the versioning 0.x right now) - so you can see many small usability and functionality changes as it evolves (not major breakage).

    • Early Access Considerations: Since it is an abstraction layer on generativeai library, you may experience more latency as it calls another library under the surface and if genai misses some particular features in generativeai (mostly due to feature missing than architectural restrictions)

Developer Implications:

  • Migration Concerns: Existing google.generativeai projects might not transition to genai seamlessly without code rewriting (as genai introduces simplified concepts that can be confusing initially). There are cases that existing code is required because feature missing in genai.

    • Fine-Grained control: If the previous code requires lower level control with parameters like top_p in config in the existing projects for generativeai, then one may not transition to genai, unless they don’t require to finetune such parameters anymore or waiting until the support becomes available.

    • Type of interaction pattern: if using streaming patterns, it is only now being released into beta with function-calling features. And may not suitable to the needs to early adopters that uses those functions for months/years now in their old codebase.

  • Dependency Management: Adding genai adds another dependency, even though it largely uses the same lower layer. Some users may not feel ready to depend on early stage beta libraries. It can create library conflicts in legacy Python projects.

  • Debuggability: When things go wrong, the “chain of delegation” of a genai to its underlying lower layer of google.generativeai adds another layer to debug where and what the root cause is. In direct google.generativeai interactions you have less levels of layers involved. It’s also possible that some of Google errors from the low level library might get suppressed by this genai facade layer to simplify errors for general users, at the expense of transparency to experts.

  • Version Control/Change Management: You’ll have to be mindful of both library versions and their impact as the genai library still actively in-development stages, meaning changes may impact your applications in non obvious ways. It adds further considerations for automated unit tests or E2E integration test if relying too heavily on such an abstraction layer.

Future-Looking View:

  • genai as the Default: Google’s trajectory indicates that genai is intended to become the recommended library for most use cases and future developer tutorials and samples will rely on it. Its simpler developer experiences would favor this direction. It’s expected new major releases/enhancements/feature adds to favor genai API rather than to enhance legacy google.generativeai.

  • Gradual Transition: Expect a prolonged coexistence period during which developers have options of which libraries to choose. It is similar to previous similar decisions on new or old client APIs made by many tech companies with many historical users.

  • Improved Feature Coverage: Expect continuous and eventual (though there is no committed timeline), almost feature parity for the genai layer so most functionalities of the original APIs is exposed in a simple manner and under the new genai API layer, reducing any need to maintain and extend legacy project codebase.

  • Ecosystem: The genai’s simplicity makes easier for the ecosystem to create new abstractions on top, as users use the simplifed core logic and APIs for integrations and abstractions to make AI enabled applications or other utilities that are common and valuable across diverse application types. The ease-of-use increases developer velocity, further enhancing genai to grow.

  • Abstraction Continues: Expect further efforts to abstract away some Google backend/service specific interactions. In a multi model world that is getting complex in architectures, users can greatly benefits by focusing on logical use case API, instead of granular details for many variants/backends with slight parameter variations that does not conceptually align or benefits them at large scale or in business case levels.

In Summary for the Developer Perspective:

genai represents a conscious effort by Google to simplify the user experience of using complex generative AI APIs by adding a simplified “developer first” interface by means of creating a new abstraction on the google.generativeai layer. However, it sacrifices control and some specific functionality (for now). Its early development status requires developers to think extra with more migration, version and potential change-management impact as a side-effect.

Choosing genai implies a commitment to leveraging new, developer friendly, simple abstraction-focused architecture of an early-stage project. Whereas choosing to remain on the underlying low level APIs represents the developers wants maximum granular control, and less API-magic (for example using different model configurations at the server end point, instead of just names of strings for genai calls). If google.generativeai serves better in the interim then genai should wait as a good future candidate API after certain critical functions are integrated from the underlying library layer. Both choices have pros and cons that developers should consider. You have to prioritize these requirements and considerations and determine how genai aligns with your engineering or project timeline and technical decisions in the architecture process, or rely on an older, established, yet less flexible underlying library APIs.

As a general rule of thumb, for general new development it’s recommended to prefer genai, but it depends on how tightly your needs requires full-control access. Expect future ecosystem support, education material to embrace the simple abstractions genai makes.

1 Like
5

vs

This is an early release. API is subject to change. Please do not use this SDK in production environments at this stage
(github project description)

could you clarify what is recommended for new projects now? thanks!