Your tracker
Work starts from the GitLab or GitHub issues and work items your team already files. No new backlog to keep in sync.
The observable software factory
Agents that ship code.
See every decision they make.
Start a run from the CLI or the web app, or label a GitLab or GitHub issue, and a team of agents (scout, planner, checker, builder, reviewer, fixer, documenter) takes it from plan to a reviewed change. Jev, a fast typed judge, picks the model tier and thinking weight for each phase and checks the work between agents.
- Bring your own harness
- Choose your workflow
- Bring your own API key
- Optional GitLab or GitHub
- Average cost per run
- $1.26
- across 5 issue_sdlc runs
- Jev judgments
- 109
- for $0.0052 in total
- Gate checks passed
- 94%
- 72 of 77
- Median judgment
- 175ms
- p95 284 ms
From real runs on this website's own repository, on one example model setup. Your costs depend on the models, tiers and thinking weights you choose.
How it works
A pipeline where every step can tell you why
Code owns the sequence. Each agent owns one bounded phase, and Jev checks the hand-off before the next one starts.
-
01 Intake
- Labelled issue
- Triage Jev
-
02 Plan
- Scout
findings_are_ coherent - Planner
plan_is_ sound - Checker
-
03 Build
- Builder
scope_matches_ request - Tests code
- Reviewer
- Fixer per file
-
04 Ship
- Documenter
- Merge / pull request
- Agent phase
- Jev judgment
- Gate between agents
- Code step, no model
Bring your own
Built around what you already use
UrboPulse is the factory around your agents, not a model reseller. It works from your GitLab or GitHub issues, runs the workflow you pick on the harness you already use, and calls models with your own API keys, so you choose the models and you pay your providers directly. On this site's repo, one week of runs used 10 models from 7 families, from Claude to Qwen, Mistral and gpt-oss.
Your workflow
Issues and work items run the issue workflows: a full build to a merge or pull request, or a scout-only pass, picked by the label. Every other workflow (plan only, build and test, quality, review) starts from the visualizer's New run dialog or the UrboPulse CLI, with a prompt and supporting documents.
Your harness
Agents run in the agent harness you already use (Claude Code or pi today). The factory adds sequencing, gates and tracing around it.
Your API key
Model calls use your key, on your provider account, at your provider's rates, with no token markup. Jev runs on TypeSafe with your own TypeSafe key. What a run costs depends on the models, thinking weights and retries you allow.
Why teams pick it
Built to be trusted, not just used
The right model for every phase
Jev routes easy phases to cheaper tiers and saves Deep reasoning for the decisions that need it.
Tiers & thinkingJudgment between every agent
Scout findings, plans and builds are checked against a threshold you set, and each verdict is recorded with its confidence.
Jev gatesNothing happens off the record
Tokens and cost by agent, every judgment, and every run's timeline, live, from your own repository.
ObservabilityModels & thinking
Jev picks the tier. You set the limits.
Jev judges how demanding each phase is and how much reasoning it needs. Code keeps that answer inside what you allow.
Tiers
Three tiers of model
Tiers are optional. Map each one to a model from your own provider, or let an agent keep its own model and have Jev choose only its thinking. The prices below are one example setup, per 1M tokens; yours are whatever your provider charges.
Light
$$$$$Reads, listings, renames, and one-file edits whose shape is already decided.
- Input
- $1.10
- Output
- $5.50
Standard
$$$$$Ordinary features and fixes across a few files, on existing patterns. Most of a backlog.
- Input
- $3.30
- Output
- $16.50
Deep
$$$$$Architecture, new abstractions, undecided approaches and hard correctness.
- Input
- $5.50
- Output
- $27.50
In this example, Deep output costs 5× Light. Whatever models you choose, routing the easy phases to the cheaper tier is where the savings come from.
Thinking weights
How long to think
Each agent lists the thinking levels it may use. Jev picks one inside that set, phase by phase.
Plans, reviews and tricky fixes.
planner for plan → Jev asked deep / high, confidence 0.82
Guardrails
Routing stays inside your policy
Confidence floor
You set how sure Jev must be to pick a model (60% in this setup, 50% by default). Below that, the agent's own defaults are used.
Per-agent allow-lists
Each agent lists the tiers it may use and the thinking levels it may reach.
Safe defaults
A default tier and thinking level apply when Jev is off, unsure, or unreachable.
Gating
A second opinion between every agent.
Jev is the fast, typed judgment the factory asks around its agents: whether an issue is worth a scout, whether a plan, a build's scope or a finding holds up, and whether a broken reply is worth a retry.
Core gates
Three checks, every run
Tallies from 5 issue_sdlc runs. A failed gate sends a correction to the same agent session, which tries again.
plan_is_sound
Every plan is concrete enough to build from.
5 calls4 passed1 failed, fixed
scope_matches_request
The build is about what was asked, and nothing else.
7 calls5 passed2 failed
findings_are_coherent
Each scout finding is specific and checkable.
65 calls63 passed2 failed
Thresholds you control
You set the confidence a gate needs to pass (80% in this setup, 50% by default), separate from the model-routing floor. An optional triage minimum sends under-specified issues back to the reporter before a scout is spent.
Caught mid-turn, not after
A stuck call is stopped when Jev is at least 85% sure it has hung, and a turn that drifts off task is turned back at 80%, at most twice per phase. Repeated tool-call loops are stopped by code.
Visibility
See every call, every cost, every verdict.
A live trace of the factory: who called which model, what it cost, what Jev judged and how sure it was.
Dashboard
The whole factory on one screen
The latest run of each workflow, then the last 14 days: runs and how they ended, what is running now, spend and tokens billed, output speed, and runs waiting at a human gate. Below that, usage by model and charts of run activity, spend and success rate. The watchers' status and a New run button sit at the top.
LLM usage
Cost and tokens, by agent and by run
Calls, tokens and cost per agent and per model, cache reads and writes, and what failed phases cost, plus runs and cost per run for each workflow.
Judgments
Every judgment, with its confidence
Judgments by kind, a histogram of passed and failed verdicts by confidence, a live feed, and drift by model: which agents wander off task.
Sessions
Every run at a glance
One card per session: its workflow, the request, the linked issue and merge or pull request, success or failure, and what it cost in money, time and tokens. Switch to the full view for a swimlane per agent.
Project memory
Every run writes it down. The next run reads it.
The installer stamps an Obsidian vault into your repository. Each session gets its own project there, written phase by phase by the agents that did the work, committed with the code, and read by every session that comes after.
One project per session
What was asked, decided, built and left open
A session's project is named like its spec, <session>_<topic>, so the same prompt run twice is two projects, never one edited twice. Its Overview carries the request word for word, a summary kept current, the status, and the code it touched. Every note links the others, so the graph shows how the work fits together.
vault/
Home.md
Projects.md the index
Conventions.md the rules
projects/<session>_<topic>/
Overview.md Plan.md
Scout.md PlanCheck.md
Build.md Review.md
Fixes.md Mobile.md
Docs.md Jev.mdWho writes what
Each agent keeps its own note
Notes are written while the work happens, so the engineer, and every agent later in the same session, can see where it stands. Decisions and outcomes, not transcripts.
| Written by | Note | What it holds |
|---|---|---|
| scout | Scout.md | What it found in the codebase |
| planner | Plan.md | The goal, the approach, the decisions and why, open questions |
| checker | PlanCheck.md | Its verdict on the plan, before anything is built |
| builder | Build.md | What was built and why |
| reviewer | Review.md | The review's verdicts |
| fixer | Fixes.md | What it changed to close a rejected review, file by file |
| porter | Mobile.md | What the mobile app needs from the change, applied or still owed |
| documenter | Docs.md | What was documented and where, after a write-up in app_docs/ drawn only from the diff |
| factory code | Jev.md | Jev's judgments, when TypeSafe is on |
Memory, with rules
Earlier work is the record. Read it, never rewrite it.
Plans keep to what was decided
Before it plans, the planner opens every earlier project that overlaps the request and lists each decision it keeps or changes under Prior decisions in the spec. The reviewer holds the build to them.
Read-only, enforced in code
Any agent may read an earlier session's project. An edit to one, or to its spec, is rolled back after the agent's turn. A prompt can ask for that; only code can guarantee it.
In your vault when the run ends
Notes ride the run's branch with the code they describe. When the run finishes, the factory copies the session's project into your main checkout, so you can read it before anything merges.
Jev, marked
A judgment is never mistaken for an agent's words
The factory's code, not an agent, writes Jev's judgments into the project: what an issue is, whether a build matches its plan, why a reply did not parse. Each one is a callout in its own colour with a #jev tag, and the project's Overview is flagged jev: true. Agents may cite them, never edit them.
Jev · scope · does not clearly match
build of 3 file(s): added the token refresh endpoint
Plain markdown in your repository
No service and no database: the vault is a folder of committed markdown, so it travels with the code and reviews in the same merge request. Open vault/ in Obsidian for the graph and the callouts, or read it in any editor.
Return on investment
What a run costs, and what it saves.
Real spend from five runs on this site's repository, on one example model setup. Your costs depend on the models, tiers and thinking weights you choose, and are billed by your own provider.
Where the money went
Example setup · 5 issue_sdlc runs · 132 calls · 6.07M tokens
| Agent | Total |
|---|---|
| planner | $2.34 |
| checker | $1.63 |
| scout | $0.88 |
| builder | $0.80 |
| reviewer | $0.51 |
| documenter | $0.15 |
| Jev (TypeSafe) | $0.0052 |
| Total | $6.31 |
Per run
$1.26
average in this example setup
Jev's oversight
0.08%
of total spend ($0.0052 of $6.31)
Calculator
Your estimated savings
Net savings per month
- Engineer time returned
- LLM spend (your provider)
- Return per $1 of LLM
- Engineer hours freed
Illustrative. The default cost per run comes from the example setup above. Enter your own: it depends on your models, tiers, thinking weights and retries.
Built-in controls keep spend predictable
Spend lands on your own provider account, and you decide how much of it to allow: per-agent tier and thinking allow-lists, a budget ceiling per run, optional human approval gates, and a label and merge-request lifecycle.
Automation
Runs start from labels. Reviews get answered.
Two watchers connect the factory to your GitLab or GitHub project, and the UrboPulse CLI runs everything else from your terminal. Nothing acts until a person has asked it to.
Issues watcher
A label is the authorization
The watcher polls your GitLab or GitHub issues and work items (every 120 s here). Each routing label starts the workflow you mapped to it, and it means a person applied it. Config is re-read on every poll, and a pause survives restarts. Issue runs never merge to your base branch: the work always arrives as a merge or pull request.
- sssf:build
adw_issue_sdlc - sssf:scout
adw_issue_scout
sssf:queuedsssf:runningsssf:donesssf:failed
Reviews watcher
Review threads get a real reply
Unresolved threads on the factory's own sssf/* merge requests are answered in the session that opened them. Trusted reviewers and ignored bots are configurable, drafts are skipped, and each reply says what changed or why not.
UrboPulse CLI
Every workflow is a slash command
Type urbopulse in a stamped repo for a terminal prompt over every workflow: /plan, /build, /plan_build_test_quality, /issue_sdlc 42. The commands are read from the workflow scripts themselves, so a workflow you add is a command as soon as it exists.
A window is one session. /plan then /build land in the same worktree, and plain text goes to one agent in that session, so talking to the builder twice is one conversation. /new starts fresh.
/ for every workflow and what it does. The footer shows the session, the agent and its model.Stamp a repo in one command
urbopulse stamp installs the factory into the repository you are in, for the harness you choose. Run it again and it only fills in what is missing. --force takes the latest fixes but never rewrites your config.
Run the whole factory from the prompt
Answer a gate with /pending, /show, /approve or /reject. /resume a failed run from the phase that failed, /doctor before you spend anything, /up for the visualizer and watchers, /archive what has ended.
Nothing hidden in the CLI
Every command runs the same workflow script you could type yourself, so the trace and the exit code are exactly the same. -p runs one line and exits with its code, for scripts and CI.
A person always pulls the trigger
The watchers act only when someone has applied a label or left a review comment, and the CLI runs only what you type. No surprise builds, no personas.