Gemini Python SDK: request, polling and streaming checks
Test a Gemini API integration by separating SDK request handling from live model behavior. This guide records six unchanged Python examples from the Google Gemini skill repository, eight bounded runs through the real Python SDK, and a cancellation case that the original polling loop does not finish.
The experiment uses synthetic HTTP responses. It makes no model calls, supplies no real API key and creates no remote environment. The results show what the pinned code sends and how the installed SDK parses the supplied responses. They do not establish generated quality, server-side memory, account permissions or production readiness.
Identify the source and runtime
The Gemini API and SDK Development resource preserves the gemini-api-dev instruction file and its migration reference at repository commit 832c8f94114dc343d86ff27296fe9335b45affa0. The complete upstream Apache-2.0 license, README and original file hashes are included. The README describes the repository as an open-source project that is not an officially supported Google product; publication here does not change that status.
The source snapshot is separate from the runtime: Python 3.12, google-genai 2.29.0, httpx 0.28.1 and pydantic 2.14.0. A fixed commit identifies the instruction bytes, not a released SDK version. The source contains six Python and six TypeScript fenced examples. Only the Python examples were exercised.
Understand the test boundary
The independent runner reads the unchanged Python blocks and checks their hashes. For examples that create a client, it injects a native Google GenAI client with httpx.MockTransport. The other examples receive an explicitly supplied client prefix. The transport returns canned JSON or server-sent events while the actual SDK performs request serialization and response parsing.
The client has a dummy key, a fixture.invalid base URL, proxy-environment use disabled, and enterprise/Vertex mode disabled. Socket connection and DNS entry points are denied and counted. Sleeps are recorded instead of performed. The cancellation example has a separate bound so the test cannot poll forever. These are visible experiment controls, not changes to the original instructions.
Zero instrumented connection attempts were recorded during these runs. That is evidence for the runner's instrumented scope, not an operating-system network audit or a guarantee about arbitrary code later added to it. Inspect the runner before executing it, and use an environment containing no production credentials.
Read the eight recorded runs
| Original example | Supplied response and observation | Boundary |
|---|---|---|
| Single-turn text | A native interaction request is serialized and the synthetic output text is printed. | No model generated that text. |
| Chained conversation | The second request contains the first synthetic interaction ID as previous_interaction_id. | No server conversation history was stored or recalled. |
| Research completed | The background request is followed by a supplied completed interaction; the loop prints its synthetic output and exits. | No research agent ran. |
| Research failed | A supplied failed status reaches the original error branch and exits. | Only this synthetic failure representation was checked. |
| Research cancelled | Two cancelled responses and two recorded sleeps are followed by a third GET attempt. The independent guard raises before that attempt returns a response. | A retained counterexample, not a successful research run. |
| Remote environment | The request contains the named agent and environment="remote"; the supplied environment ID is printed. | No sandbox was provisioned or file written. |
| Custom agent | The SDK serializes the agent definition, repository source configuration and subsequent invocation. | No repository was accessed and no code review occurred. |
| Text streaming | The SDK parses supplied SSE text deltas and a final usage object; the example prints the synthetic text and token total. | No live stream or actual billing usage was measured. |
Bound background polling
The original Python research loop checks completed and failed, then sleeps for every other status. In the recorded cancelled case, it keeps retrieving the cancelled interaction. The runner deliberately stops the experiment; it does not rewrite the source or report the loop as correct. The official background-execution guide distinguishes cancellation and a request for client action from successful completion.
Before adapting a polling workflow, define the states your application treats as success, failure, cancellation and a request for further action. Add a maximum duration or poll count, a delay policy, and a way for the user to stop. Preserve a distinct result for cancellation so it cannot become a success message. Check transport exceptions and recovery behavior in the complete application.
The current official Interactions overview explains stored interactions and chained IDs. Storage controls affect conversation continuation and background execution. This local experiment does not test retention, deletion, privacy terms or server-side authorization; consult the current service documentation before sending real data.
Separate streams from agent execution
A parsed text delta proves that the client can handle the supplied event shape. It does not prove that a live stream stays connected, delivers every chunk or recovers from an interrupted request. The fixture covers text and a final usage object; it does not cover image/audio chunks, tool calls, reconnects, partial errors or bidirectional Live API sessions.
Likewise, serializing environment="remote" proves which field was sent. It does not establish that the account can create an environment or that a managed agent can read a repository. Custom-agent creation emitted an experimental SDK warning in the recorded environment. Keep that warning and recheck the relevant API documentation and access scope before any real creation action.
The model and agent IDs preserved in these requests are source example strings. They were never resolved by a live endpoint. The retained migration reference also contains different legacy-model advice from the primary instruction file. Compare both with current official model and migration documentation rather than inferring availability from a successful mock response.
Reproduce the package without a live key
Download the resource, verify its SHA-256 against the resource page and read examples/README.md. Use a dedicated environment with the recorded Python dependencies. Run the independent examples/run_fixture.py from the extracted package; it writes fresh evidence under examples/output and preserves the shipped record.
The actual downloadable ZIP was extracted and the runner executed again using the same installed dependency environment. All eight recorded runs, original block hashes and dependency records matched, apart from the timestamp. This was an archive reproduction, not a claim that a fresh dependency installation was performed for that second run.
The package excludes installed environments, generated output, binary media and real credentials. Do not paste a real API key into the runner to make a mock test pass. A dependency import error needs an environment fix; it should not be resolved by silently replacing the native SDK with a hand-written imitation.
Choose the next check for your application
| Your integration | Useful next evidence | This experiment does not supply |
|---|---|---|
| Conversation UI | Ownership checks for stored IDs, explicit data retention and error handling | Real identity, server memory or authorization results |
| Background research | Bounded polling, cancellation, deadlines and recovery in your application | Research quality or live terminal-state behavior |
| Streaming UI | Interrupted streams, partial output, reconnect policy and tool-event handling | End-to-end streaming reliability |
| Managed agent | Exact repository and environment permissions before creation | Remote execution or repository access |
| Public API | Request/response contracts, validation and controlled error responses | Production API security or deployment validation |
The Pydantic API Model Contracts skill helps inspect validation boundaries, and the FastAPI development skill provides context for response models and dependencies. Use Vitest for independent JavaScript state and error checks, and Playwright CLI to extend a finished application test to actual browser controls. Each resource has separate requirements and evidence; these links do not establish compatibility between all of them.
Keep license, cost and evidence separate
BB Skills acquired the source through free channels and preserves its Apache-2.0 license and attribution. The independent fixture additions have a separate MIT notice. A free, redistributable instruction package does not establish that every API, managed environment or storage service mentioned by it is free to operate. No paid API or remote agent action was performed for this guide.
The resource retains runtime_tested: false because the complete AI-client skill was not executed. The scoped SDK experiment, counterexample, hashes and dependency record explain exactly what was observed. There is no TypeScript, multimodal, TTS, real-time Live API, production account or performance benchmark result.
BB Skills prepared this original guide and independent runner with AI assistance and reviewed the recorded outputs. Sources: the fixed upstream instruction file, its retained migration reference and README, the official Python SDK reference, and the official streaming guide. No provider endorsement, generated-quality result or search-ranking outcome is claimed.