Google: Gemini 3.7 Flash (batch)

Google: Gemini 3.7 Flash (batch) is a multimodal text model from Google, offered through api14 under the model id google/gemini-3.7-flash:batch. It belongs to the Gemini 3.7 Flash line, which Google describes as built for fast agentic workflows, coding, and complex multi-step reasoning. The batch variant is the same model surfaced for batch style usage rather than interactive request patterns.

The model accepts text, image, video, file, and audio inputs, and returns text only. Its context window is 1,048,576 tokens, with a maximum output of 65,536 tokens. That combination of a very large input budget and a substantial output ceiling means you can pass long documents, media, or multi part inputs in a single request and still get a lengthy structured response back. Reasoning behaviour is exposed through parameters rather than being fixed, so you can decide how much internal deliberation the model performs.

Practical uses follow from those capabilities. Long context plus mixed input modalities suits document and media analysis, such as summarising or extracting structured data from lengthy reports, transcripts, or recordings. Coding tasks fit the stated focus on agentic workflows, particularly where the model needs to read several files or a large codebase before answering. Multi-step reasoning over large inputs is another fit, for example research style question answering that has to reconcile many sources. Because output is text only, the model is a good choice when you need written answers, structured JSON, or tool calls rather than generated media.

To call it through api14, use the OpenAI-compatible endpoint with the model id google/gemini-3.7-flash:batch. The supported request parameters are include_reasoning, max_tokens, reasoning, reasoning_effort, response_format, seed, stop, structured_outputs, tool_choice, and tools. In practice that means you can cap output length with max_tokens, control reasoning depth with reasoning_effort or the reasoning parameters, request structured output through response_format or structured_outputs, make sampling more reproducible with seed, define stop sequences, and wire up function calling with tools and tool_choice.

One thing to weigh is the batch orientation implied by the model id. If your application needs low latency interactive responses, a non batch variant of the same model may be the better fit, since the parameters and modalities here are otherwise the same. Also note that output is text only, so any task requiring generated images, audio, or video needs a different model. The 65,536 token output cap is generous but finite, so very large single responses may need to be split across calls.