Idea to working software in a user's hands, first time.
Including release mechanics, QA gating and handoff waits.
Typically −70.8%. The upper bound needs a legacy codebase and a recorded history.
Every number on this page is labelled either measured or modelled, and the two are never mixed. Measured means we instrumented this server and you can reproduce it. Modelled means it is arithmetic over assumptions that are written down below, line by line, so you can disagree with any of them and recompute. We do not have twelve months of customer telemetry, and a page that implied otherwise would not survive the first hard question.
Does an MCP server save tokens? Honestly — that is the wrong question
This gets asked first, so here is the measurement before the argument. On 7 August 2026 we instrumented the Oprex MCP server against a Postgres corpus of 1,363 artifacts — 423 issues, 261 tickets, 181 requirements, 312 test cases, 25 specifications, 142 notes, 19 milestones — roughly one year of a small team's output.
| What | Cost | Note |
|---|---|---|
Tool definitions loaded once per session (tools/list) | ≈ 11,890 tok | 46.4 KB, 51 tools. This is a cost, paid before you ask anything. |
One oprex_search call | ≈ 491 tok | 8 ranked hits across all 7 kinds, snippets only. |
| Same question via 3 filtered list calls | ≈ 798 tok | Full rows. Covers 3 of 7 kinds, and misses stem variants. |
| Same question by reading the whole backlog | ≈ 555,077 tok | 2.1 MB. Nobody does this — but it is the ceiling agents drift toward without search. |
So: the tool definitions cost about 11,900 tokens per session, and one search saves about 300 tokens against a filtered list. On token count alone the break-even is roughly 39 lookups in a single session. Most sessions do not do 39 lookups. If a vendor tells you their MCP server saves tokens, ask them for this table.
The saving is real, but it is not in the retrieval. It is in the work that never happens: the file you do not have to read to reconstruct a decision, the bug you do not re-diagnose because the earlier report is right there with its reproduction, the twenty minutes of a human re-explaining a constraint that was settled in March. Those are not 300-token savings. A single avoided round of “let me go read the auth module to figure out why this is like this” is tens of thousands of tokens and a chunk of an afternoon.
There is a second effect that matters more than the arithmetic and is harder to sell: a shorter, more relevant context produces better answers than a long one. An agent handed 500,000 tokens of backlog does not reason 1,000× better than one handed 500 tokens of ranked, on-topic hits — it reasons worse, because the signal is buried. Retrieval quality, not retrieval volume, is what changes the output.
Two more things we measured
Search stays fast as the corpus grows. Full-text search runs on a generated tsvector column with a GIN index, indexed under both the Indonesian and English stemmers because real Indonesian technical writing is a mix. On the 1,363-artifact corpus, Postgres reports a Bitmap Index Scan completing in 0.026 ms — the index is used, not bypassed. Query cost does not grow with the size of your backlog the way “read it all” does.
The stemmer earns its place. A search for mendaftar also returns records that only ever wrote pendaftaran or daftar, because all three stem to the same root. Substring matching — what most search boxes actually do — finds none of them. That is the difference between “we have search” and “search finds things”.
Why time to product drops about 30%
The model below is deliberately unflattering to us: it assumes writing the code takes exactly as long as it always did. What changes is everything around it. Shares are of one team-week of a delivery cycle for a small product team.
| Where the time goes — time to product | Share | Cut by | Net |
|---|---|---|---|
| Re-deriving context at the start of each session Reading code and old chats to answer “what did we decide about this?”. Replaced by recalling facts and reading the project's own record. |
12% | −70% | −8.4% |
| Authoring requirement → spec → test case The chain exists as data, so each link can be drafted from the one above it instead of from a blank page. A human still approves. |
18% | −50% | −9.0% |
| Re-discovering a bug someone already reported One ranked search across issues, tickets, requirements, specs, tests, milestones and notes before opening anything new. |
7% | −60% | −4.2% |
| Assembling release notes and the changelog Notes are generated from the release plan's scope items, which were already linked to the work. |
5% | −80% | −4.0% |
| Status reporting — “where are we” meetings and recaps The board, the coverage matrix and the activity stream are the report. Nobody assembles it by hand. |
8% | −55% | −4.4% |
| Everything else — designing, writing and reviewing the code Half the week, untouched. It is listed rather than omitted because a model whose shares do not sum to 100% is not a model, and because this row is what limits the claim to 30%. |
50% | −0% | −0.0% |
| Total | −30.0% |
Read this as cycle time down 30.0%, which is about 1.4× the throughput for the same team. If you think context re-derivation is 5% of your week rather than 12%, the total drops to about 25% — change the row and recompute. That is the point of showing the table, and of the last row: half of a delivery week is code, and Oprex does not touch it.
Why time to market drops about 40%
Time to market is time to product plus everything between “it works on my machine” and “a customer is using it”. That second part is mostly mechanics and waiting, which is exactly what a system of record removes.
| Where the time goes — time to market | Share | Cut by | Net |
|---|---|---|---|
| The build phase itself Carries the time-to-product model above, weighted at 70% of total time-to-market. |
70% | −30% | −21.0% |
| Release plan → shipped release Scope, notes and publication are one action on a record that already exists, not a checklist executed by hand. |
9% | −75% | −6.8% |
| CI provisioning for a new repository A new project gets its Git repo and pipeline provisioned on creation. No per-repo YAML archaeology. |
5% | −80% | −4.0% |
| QA gating before release The coverage matrix answers “which requirements have no passing test” continuously, instead of a manual traceability audit per release. |
8% | −60% | −4.8% |
| Handoff waits between roles No “who has the latest doc” — the artifact is the same object for the analyst, the developer, the tester and the agent. |
8% | −45% | −3.6% |
| Total | −40.1% |
The total is −40.1%. The first row carries the previous model forward, so the two numbers are consistent rather than two independent guesses. The remaining 30% is where the difference between −30% and −40% comes from: release mechanics and handoffs are the most mechanisable part of shipping, and the least interesting to do by hand.
Why maintenance drops the most — and where “up to 80%” comes from
Maintenance is the strongest claim on this page and the one with the clearest mechanism. Very little of maintaining software is typing. Most of it is establishing what is true before you dare change anything: why the code is shaped this way, who decided it, whether the odd-looking branch is load-bearing, and what will break.
| Where the time goes — maintenance | Share | Cut by | Net |
|---|---|---|---|
| Archaeology — why is this like this, who decided, is it load-bearing The dominant cost of maintaining code you did not write last week. Answered by facts with an asserted date, a reason, and a link to the requirement or incident they came from. |
45% | −85% | −38.3% |
| Reproducing a bug that was reported once before Search finds the earlier report with its reproduction steps attached, including the ones that were closed. |
15% | −80% | −12.0% |
| Re-testing what a change might have broken Requirement × test case × last result is a query, not a spreadsheet somebody maintains. |
18% | −70% | −12.6% |
| Writing the paperwork around the fix The agent files the issue, the test case and the release note as it works. |
10% | −80% | −8.0% |
| The actual code change Unchanged. Oprex does not make typing faster, and claiming otherwise would be the tell that the rest is invented too. |
12% | −0% | −0.0% |
| Total | −70.8% |
The model lands at −70.8%, not −80%. The higher figure needs a codebase where archaeology is a bigger share than the 45% assumed here — a legacy system, a team that has turned over, code whose author has left. Raise that row to 60% and shrink the rest to keep the shares at 100% (on that kind of system the fix genuinely is small next to the investigation) and the total reaches −79.1%. That is where “up to 80%” comes from: an upper bound with a stated condition, not a headline.
And it has a precondition that is worth being blunt about: this only pays off if the decisions were actually recorded. Oprex makes recording cheap enough that an agent does it while it works, but a project where nobody ever wrote anything down gets none of this. The first three months are when you are paying in, not drawing out.
What this looks like on one concrete task
A customer reports that registration fails when the email already exists. A developer picks it up on a Tuesday morning.
Without a system of record
Search the chat history. Ask in the group whether this is known. Read the auth module to work out the intended behaviour. Reproduce it. Write the fix. Realise afterwards that a requirement from March already specified the exact error message, and the fix used different wording. Ship. The next person repeats all of it.
With Oprex over MCP
One search returns the closed issue from March with its reproduction, the requirement that fixed the wording, the test case that covers it, and a note saying do not use upsert here — the race condition is real. The fix matches the specified behaviour on the first attempt, and the issue, test result and release note are filed as the agent works.
Nothing in the right-hand column is a new capability. It is the same information that existed in the left-hand column — it was simply never written down anywhere a machine could find it.
If you are migrating an existing team
The numbers above assume the record exists. Migrating is how it starts existing, and being honest about the shape of that curve matters more than promising it is painless.
- Import, do not re-enter. Existing issues come in over the REST API or the CLI; Git repositories connect to what you already have on GitLab or GitHub. Nobody retypes a backlog.
- Expect to pay in for a few weeks. A backlog imported without decisions attached is a list, not a memory. The compounding starts when sessions begin recording as they go — which is a standing line in your
CLAUDE.md, not a process change anyone has to remember. - Start with one project, not the whole company. One team, one repository, one release cycle. You will know inside a month whether the model above holds for how you actually work.
- The agent does the writing. This is the part that makes it stick. Every previous attempt to get a team to document decisions failed for the same reason: it was extra work for a human, paid now, benefiting someone else later. When the agent already has the context in hand, writing it down costs one tool call.
How to check any of this yourself
The measured figures come from this repository's own test and instrumentation path, against a local Postgres with the corpus described above. If you run Oprex yourself, the same numbers are a search away:
# one ranked query across every SDLC artifact curl -H "Authorization: Bearer <your-key>" \ "https://oprex.id/api/v1/search?q=pendaftaran+email+sudah+terpakai" # the same tool your agent gets, over MCP claude mcp add --transport http oprex https://oprex.id/mcp \ --header "Authorization: Bearer <your-key>"
The tool-definition cost is whatever tools/list returns for your client — measure it, do not take our word for it. Everything else on this page is arithmetic you can redo with your own shares.
Run the experiment on one project
The free plan includes MCP, search, and Memory. Connect it, work one real cycle, and see which rows of the model hold for your team.
Open your workspace Read the guides