pyspur

Thanks! Yes, will push it as template to our repo (https://github.com/PySpur-Dev/pyspur) soon! We used o1 and claude3.5

Neat! I was looking for something like this the other day. Some feedback on the Dockerfiles - I'd recommend instead of trying to mount in the source code as volumes, clone the repo in the Docker build process. That will be a lot more reliable and make it easier for people to deploy. You'll also need to call out if any volumes are required to be mounted to persist data (config files, sqlite databases, cache etc...) E.g. something like this - Dockerfile.backend: FROM python:3.12 RUN apt-get update && apt-get install -y git && apt-get clean && rm -rf /var/lib/apt/lists/* RUN git clone --depth=1 https://github.com/PySpur-Dev/PySpur.git /pyspur WORKDIR /pyspur/backend RUN pip install -r requirements.txt VOLUME ["/data"] CMD ["bash", "/pyspur/backend/entrypoint.sh"] Dockerfile.frontend: FROM node:alpine RUN apk a

We built several LLM-powered applications that collectively served thousands of users. The biggest challenge we faced was ensuring reliability: making sure the workflows were robust enough to handle edge cases and deliver consistent results. In practice, achieving this reliability meant repeatedly: 1. Breaking down complex goals into simpler steps: Composing prompts, tool calls, parsing steps, and branching logic. 2. Debugging failures: Identifying which part of the workflow broke and why. 3. Measuring performance: Assessing changes against real metrics to confirm actual improvement. We tried some existing observability tools or agent frameworks and they fell short on at least one of these three dimensions. So we built our own: https://github.com/PySpur-Dev/PySpur 1. Graph-based interface: We can lay out an LLM workflow as a node graph.

Hey HN, We’re excited to share PySpur, an open-source tool that provides a graph-based interface for building, debugging, and evaluating LLM workflows. Why we built this: Before this, we built several LLM-powered applications that collectively served thousands of users. The biggest challenge we faced was ensuring reliability: making sure the workflows were robust enough to handle edge cases and deliver consistent results. In practice, achieving this reliability meant repeatedly: 1. Breaking down complex goals into simpler steps: Composing prompts, tool calls, parsing steps, and branching logic. 2. Debugging failures: Identifying which part of the workflow broke and why. 3. Measuring performance: Assessing changes against real metrics to confirm actual improvement. We tried some existing observability tools or agent frameworks and they