LangExtract

This article is based on a tested environment of langextract 1.7.1, openai 3.35.1, and Python 3.13, and the author states that they developed the gateway APIClaw used in the examples, so views related to the gateway should be taken with reservation.

LangExtract's default backend is Gemini, but it includes a built-in provider based on the official OpenAI SDK, which in theory can connect to vLLM, LiteLLM or any hosted gateway.

LangExtract's provider routing is based on regex matching of model_id: only names starting with gpt-3.5, gpt-4, gpt-5 or o1 through o9 will go to the OpenAI provider.

In langextract 1.7.1, model_ids starting with qwen, deepseek, llama, mistral, gemma, phi, gpt-oss, etc. are routed to the Ollama provider, even if model_url is passed in.

LangExtract is a Python library developed by Google that can extract structured entities from long texts and map each extraction back to its character position in the source text.

LangExtract only reads the OPENAI_API_KEY environment variable when the model ID contains gpt; when a provider is explicitly specified and the model name does not contain gpt, api_key must be passed explicitly, otherwise it reports API key not provided.

When base_url is not passed, LangExtract reads the OPENAI_BASE_URL environment variable, and either way the trailing /v1 must be kept on base_url.

Each of LangExtract's text chunk requests contains one system message (requiring a JSON reply), one user message containing the prompt, Q:/A: examples and the chunk text, n: 1, and a json_schema-type response_format named langextract_extractions with strict: true.

LangExtract's default requests contain neither temperature nor max_tokens, and are entirely governed by server-side defaults; when set explicitly in provider_kwargs, the request will carry the corresponding parameters.

When the server returns 400 for json_schema, LangExtract's extract() throws InferenceRuntimeError: OpenAI API error: Error code: 400.

After setting use_schema_constraints=False, LangExtract requests switch to response_format: {"type": "json_object"}, which works around servers that do not support json_schema.

By default, LangExtract silently swallows parsing errors for each chunk: when the model output is wrapped in explanatory text and fences, or when JSON parsing fails because it was truncated due to finish_reason being length, that chunk is discarded and only a log is printed, returning zero extraction results without throwing an exception.

In json_object mode, LangExtract expects bare JSON; if the model returns a JSON block with explanatory text and fences, it is discarded, with the log reading Chunk omitted from results (parse error): Failed to parse JSON content.

In testing, when model_id was qwen3-coder-plus, LangExtract sent a POST to <base_url>/v1/api/generate and returned an error that the Ollama model could not be found; plain-model, which matches no pattern at all, reported No provider registered for model_id.