Ollama runs one model at a time. Send it a prompt, get a response. For single-turn chat, that's enough.
But useful work often chains capabilities. You record a meeting, transcribe the audio, summarize the transcript, and extract action items. Each step needs a different model or tool: a speech-to-text model, a language model for summarization, maybe another pass for structured extraction. Ollama handles one of those steps. The orchestration - deciding what feeds into what, moving data between models, handling failures - is your problem.
The usual workaround is a Python script that calls Ollama's API in a loop, piping output from one model into the next. It works. Then you want to swap the summarization model, or add a translation step, or figure out why step three produced garbage. Now you're maintaining a custom orchestration layer for something that should be a drag-and-drop operation.
That's the gap pipelines fill: a visual way to chain models and capabilities without writing glue code. The blocks run on ToolPiper's built-in engine - upstream llama-server, build b9533, with models downloaded as plain GGUF from Hugging Face - and if your model library lives in Ollama, those models work as blocks too.
What is a pipeline in ModelPiper?
A pipeline is a visual workflow where each block represents a model or operation. Data flows from one block to the next through connections you draw on a canvas. You're building workflows, not writing prompts.
Each block has a type: text generation, speech-to-text, text-to-speech, OCR, embedding, image upscale, and others. When a block's type is text generation, it can use any model from any connected provider - ToolPiper's built-in llama.cpp engine, an existing Ollama instance, or a cloud API. The pipeline builder handles the data flow between blocks automatically.
Pipelines are data-driven. The configuration for each block (which model, what parameters, how to transform the output) is stored as JSON. You can duplicate a pipeline, swap out one block, and have a variation running in seconds. No code to maintain.
What can you build with local models in a pipeline?
Three example pipelines. Each runs on ToolPiper's native engine out of the box - swap any LLM block to an Ollama model if that's where your library lives. Each solves a real problem that single-model chat can't.
Voice conversation: STT → LLM → TTS
The simplest multi-model pipeline. A speech-to-text block (Parakeet v3) transcribes your voice input. The transcript feeds into a local chat model for reasoning. The model's response streams into a text-to-speech block (PocketTTS, Soprano, or Orpheus) that reads it aloud. STT and the chat model are free; the TTS engines are part of Pro ($10/month).
Three blocks, three different AI capabilities, one workflow. ToolPiper ships this as the tp-local-voice-chat template. For a deeper walkthrough, see voice chat with Ollama on Mac.
Document Q&A: OCR → Embed → Index → Chat
Drop a scanned PDF into the pipeline. An OCR block (Apple Vision) extracts the text. An embedding block converts the text into vectors and indexes them in a local collection. A chat block with RAG context answers questions about the document, citing specific passages. OCR and embeddings are free; the RAG retrieval step is part of Pro ($10/month).
This is the workflow that makes local AI practical for professionals with document-heavy work. Contracts, research papers, internal reports - they stay on your Mac and become searchable through natural language.
Multilingual content: Chat → Translate → TTS
Ask your chat model a question in English. The response feeds into a second chat block with a translation system prompt. The translated text streams into a TTS block that reads it aloud in the target language.
Each block handles one task. The pipeline builder handles the wiring. Changing the target language is a one-field edit in the translation block's system prompt, not a code change.
How does Ollama fit into the pipeline?
It doesn't have to. LLM blocks run on ToolPiper's built-in engine by default - the same upstream llama-server that handles chat - with models downloaded from Hugging Face as plain GGUF files. No CORS setup, no OLLAMA_ORIGINS, no second process to keep alive. If you're starting fresh, that's the whole answer: the engine is already there, free, no account.
If you're connecting an existing Ollama instance, the case is your library. You've already invested time finding and pulling the right models - a 7B coding model, a 3B fast-chat model, maybe a 13B for complex reasoning. Add Ollama as an external provider and every pulled model appears in the model dropdown alongside ToolPiper's native models and any cloud APIs you've configured. No re-downloading, no format conversion. In a pipeline, you can use each model where it's strongest - the fast one for classification, the large one for generation - without managing separate API calls or scripts.
The connection works through Ollama's API on localhost:11434, and you'll need OLLAMA_ORIGINS configured for the browser-based pipeline builder to reach it. That's the migration path, not the destination - the full comparison covers what switching to the native engine looks like.
How do you build a pipeline from scratch?
We'll build a two-block pipeline: transcribe an audio clip, then summarize the transcript with a local chat model. A practical workflow for meeting notes, podcast summaries, or lecture review.
Open the pipeline builder in ModelPiper. The canvas starts empty. Drag an STT block from the block palette onto the canvas. This block will handle speech-to-text using Parakeet v3.
Drag a text generation block next to it. Click the block to open its settings and pick a model - Llama 3.2 3B from the built-in catalog is a good default for summarization tasks, and if you've connected Ollama, your pulled models sit in the same dropdown. Set the system prompt to something like "Summarize the following transcript in 3-5 bullet points. Be concise."
Draw a connection from the STT block's output port to the chat block's input port. The line represents data flow: when the STT block finishes transcribing, the text automatically feeds into the summarization model.
Hit run. Drop an audio file into the STT block's input. Parakeet transcribes it, the transcript flows to the chat model, and the summary appears in the output panel. Two models, one click, no scripting.
Want to extend it? Add a TTS block (Pro, $10/month) after the summary to read the bullet points aloud. Add a translation block between summarization and TTS to get the summary in another language. Each extension is another block and another connection, not another script to maintain.
What are the limitations of local pipelines?
Latency compounds. Each block in the pipeline adds processing time. A three-block voice pipeline (STT + LLM + TTS) adds roughly 1-2 seconds of total overhead on an M2 Max. A five-block pipeline with OCR, embedding, retrieval, chat, and TTS will take longer. For real-time interactive workflows, keep the chain short. For batch processing (transcribe a folder of audio files), latency per step matters less.
Memory adds up. Each model block that loads a different model needs its own RAM allocation. A voice chat pipeline with STT + 3B LLM + TTS needs about 3GB. A document Q&A pipeline with OCR + embeddings + 7B LLM might need 6-7GB. ToolPiper's resource monitor shows whether a pipeline's models fit before you run it.
Single-model chat doesn't need a pipeline. If you're asking a question and reading an answer, the pipeline builder is overhead. Open the chat panel and talk to the model directly. Pipelines earn their complexity when the workflow involves more than one capability - voice, vision, translation, document processing, or model chaining.
Pipeline debugging takes patience. When a multi-block workflow produces unexpected output, you need to inspect each block's input and output to find where the chain went wrong. The pipeline builder shows per-block results, which helps. But debugging a three-step pipeline is inherently more work than debugging a single prompt.
Download ToolPiper at modelpiper.com and open the pipeline builder. The starter model that downloads on first launch works in every text generation block - and if you connect Ollama, your pulled models show up next to it.
This is part of our Ollama series. See also: Voice Chat With Ollama - the simplest pipeline you can build. Next: Ollama Vision GUI on Mac - use LLaVA without the terminal.
