dronelabour-dllm: LLM APIs and File-Based Prompts

Manage LLM requests in files, then call them by prompt name and parameters from Python. dllm.connector, part of dronelabour-dllm, handles provider calls while your application supplies the inputs and uses the results.

Use it to keep prompts separate from application logic, maintain provider-specific requests for the same generative task, switch callers in code, and compose calls into pipelines.

Separate prompts from application code

A prompt file holds instructions, model settings, provider-specific request fields, and named input parameters. Python code loads the file, selects a named prompt, and supplies values for the current call.

You can review and version prompt changes alongside your application, refining instructions and settings without embedding the full provider request in every call site.

Install the package as dronelabour-dllm; import its modules using dllm. The example below uses dllm.connector.asyncio.chat.

Call a prompt by name

Install the package in your Python environment:

pip install dronelabour-dllm

Save this as prompts/example.json. Replace YOUR_OPENAI_MODEL with a model available to your account that supports the Responses API. Configure the credentials required by the provider before running the example.

{
  "prompts": [
    {
      "name": "answer_question",
      "providers": [
        {
          "label": "openai-responses",
          "isdefault": true,
          "genparams": {
            "model": "YOUR_OPENAI_MODEL",
            "instructions": "Answer the question clearly and concisely.",
            "input": "{question}"
          }
        }
      ],
      "queryparams": [
        { "type": "string", "name": "question" }
      ]
    }
  ]
}

Load the file and supply a value for the named parameter:

import asyncio

from dllm.connector.asyncio.chat import LocalClient


async def main():
    client = LocalClient("prompts/example.json")
    responses = client.openai_responses("example", "answer_question")
    parameters = client.dict({"question": "What is the capital of France?"})

    try:
        result = await (parameters | responses)
        print(result.text)
    finally:
        await responses.aclose()


asyncio.run(main())

example is the prompt filename without its extension. answer_question selects the prompt, and client.dict() supplies the value that replaces {question}. The code prints the provider's answer; its exact wording can vary.

This example omits the optional Redis response cache. The API reference explains caching and parameter behaviour.

Define provider alternatives for the same task

A task such as answering a question can have different request definitions for different providers. Keep those definitions with the named prompt and use a consistent set of application parameters where practical.

Provider settings remain specific to the selected API. OpenAI Responses and Google Gen AI requests, for example, use different request fields. DLLM separates those definitions from call sites; it does not make provider capabilities or results identical.

The current connector reference documents OpenAI Chat Completions, Responses, and image generation, plus Google Gen AI GenerateContent, Interactions, and Imagen. Follow its caller definitions and linked provider specifications when preparing requests.

Switch provider callers in Python

Choose the caller for the provider you want to use. These selections address the same task name and require matching provider definitions in the prompt file:

responses = client.openai_responses("example", "answer_question")
gemini = client.gemini("example", "answer_question")

The earlier JSON example defines only the OpenAI Responses request. Add the appropriate Google Gen AI definition before using the Gemini caller.

Your application chooses which caller receives its parameters. Keep shared input names consistent and handle each caller's result type as documented. Switching callers is an explicit code choice, not automatic provider fallback.

Compose calls into pipelines

The | operator passes a parameter object into a configured caller:

parameters = client.dict({"question": "What is the capital of France?"})
result = await (parameters | responses)

Build a multi-step workflow by taking one call's result and supplying it as a named parameter to the next. For example, one prompt can summarize a document and another can translate the summary. Each task keeps its own prompt definition and provider settings; Python controls the order and maps results between steps.

See the API reference for dict(), single(), image and file inputs, and the caller interfaces used in these operations.

Add LLM calls to your application

Use the connector wherever your Python application needs configured LLM calls. The documented cloud-provider calls require network access and provider credentials; storing prompts locally does not make inference local.

To build a conversational application managed by DLLM Desktop, start with ChatTemplate, which uses the dllm.chatapp application base in the same package. Add connector calls where your application needs LLM-powered behaviour. The Getting Started guide covers the first application and its change-and-restart cycle.

Continue with the API reference for exact interfaces, the Python package and source repository for the library, or the MCP guide to give your coding agent access to DLLM documentation.