PaloSpring
PaloSpring is a self-hosted, open-source agent runtime for builders whose ideas move faster than their tools. The pipeline is designed to lose nothing; every directive, every intention, and every burst of vision from the user is captured, documented, and carried forward into the implementation. The Council exists to make sure none of it gets dropped.
You write the vision. PaloSpring runs the operation.
Local control first
The runtime runs on your hardware, under your control. Configure model access, assign stages to providers, and operate from a terminal interface that keeps every agent decision visible. There are no cloud dependencies unless you choose one.
The pipeline is a defined sequence of gates. Each phase passes a structured artifact to the next. Nothing proceeds until it clears its gate. The Council evaluates the full result before any round is declared complete.
Onboarding
Type "palospring".
The runtime opens into a selection panel where you choose a workspace to begin a new session scoped to that directory, or load a previous session from your run history -- either the full global history or filtered to the current workspace. The scope of the run is established at this step.
Once a workspace is confirmed, the runtime opens the PALO::TASK panel where the task is written. The orchestrator model is available to assist with structuring the prompt, but is not required. When the task is submitted, the pipeline begins.
Research
No implementation until the brief is confirmed.
Before any code is written, the runtime evaluates whether a prior run already covers part of the task. If a matching artifact exists in cache, the pipeline advances directly to the relevant stage. Otherwise it opens with pre-research, which reads the current state of the workspace and surfaces clarifying questions before planning starts.
Research then runs: the researcher dispatches queries, fetches and distills results, checks for evidence gaps, loops back to fill them, synthesises the findings, and verifies citations before passing a confirmed research brief forward. The pipeline does not proceed past research until the brief clears the research gate.
Architecture
A blueprint before any code is written.
The architect receives the research brief and produces a system blueprint: file structure, module boundaries, and implementation scope. The blueprint passes through a preflight gate that runs deterministic structural checks before any code is written. If preflight fails, the architect revises and resubmits, with a hard cap of two attempts before the run surfaces a fault.
A critique pass then evaluates the approved blueprint before the pipeline moves to execution. Each agent receives only the information its stage requires -- not a full conversation history, not a compressed summary, but the specific output of the preceding stage.
Coder
Implementation validating itself
The coder works from the confirmed architecture blueprint and produces the full implementation. For complex tasks, arc routing determines whether implementation runs as a single pass or across parallel branches that are later merged by the integrator. The coder can retry on failures, return to the architect if the manifest is stale, and pass through Spring mode if evolutionary optimisation is enabled.
After integration, the validation ladder runs structural checks. Then QA takes over, running tests, triggering self-healing on failures, and looping back to the coder when corrections are needed. The pipeline closes when QA passes.
The Council
The deliberation layer. After every round, and throughout the pipeline.
Most agent tools accept user input freely during a run -- a message typed mid-pipeline halts the agent and redirects it. PaloSpring does not work this way. When you raise a question or concern during an active run, it goes to the advisory council rather than directly into the workflow. The council evaluates it; if the concern has merit and the pipeline should change course, the council acts on it. If the concern would lead to a worse result, the council makes that case before anything changes.
After the first round closes, the full Council convenes. A panel of specialised agents evaluates the implementation against the original task. Each agent casts a structured vote -- [GRANT], [DENY], or [ABSTAIN] -- with a one-sentence justification and a confidence score. The panel renders live in the TUI as turns arrive. You are in observer mode by default: watching a live audit, not participating in a conversation.
If any agent votes [DENY], a standoff is declared. The COMMENCE button is locked. You have two resolution paths: inject a directive that addresses the denying agent's concern and allow the council to re-evaluate, or invoke a Visionary Override, explicitly accepting the risk and proceeding against the denial. Every override is logged to .palo/audit/ with a hash, a timestamp, and the specific concern that was overruled.
Model Routing
One API key is enough. Stage routing is available when you want it.
Stage routing is available when you want different models handling different phases -- research to one provider, architecture to another, implementation to a local model. Model health scoring tracks which models are responding correctly across the run and routes around failing ones automatically so the pipeline keeps moving without manual intervention.
PaloSpring supports Ollama, MLX, Gemini, NVIDIA NIM, and any OpenAI-compatible endpoint. The runtime has no cloud dependency unless you choose one.
Open Dataset
Contribute anonymised task-and-output pairs to a public dataset.
If you choose to opt in, anonymised task-and-output pairs from your runs are contributed to a public dataset available to researchers, builders, and anyone training on real agentic workflows. The option is off by default and requires a single configuration change to enable. The dataset is public, not proprietary to Mpalo.
Effort Mode
Four levels of pipeline depth: Low, Medium, High, and Extra High. Higher effort means deeper research cycles, tighter architectural critique, and more improvement rounds before the Council convenes for the first time. The default is calibrated to deliver a working result as efficiently as possible.
Start here
Start by reading the documentation and cloning the repository.
PaloSpring is open source, self-hosted, and runs on your hardware from the first run.