Why you should use Oprex.id?
Oprex is the system of record your AI agent reads before it writes code. Three conditions, three very different afternoons.
What is "vibe coding"?
Vibe coding is what happens when you hand a coding agent a real project instead of a toy example. The agent reads your code, your decisions, and your defects — then writes code that fits. Oprex supplies two of those three things: the project record (issues, requirements, test cases, facts) and the release mechanics. Your IDE or editor supplies the code.
Code indexing is not an Oprex feature. The "code indexing" you may have heard about belongs to Kilo Code — it indexes your local codebase so the agent understands symbols, references, and definitions inside your editor. Oprex MCP does something different: it indexes your SDLC data (issues, tickets, requirements, specifications, test cases, milestones, notes, and memory facts) so the agent understands what the project decided and why. Together they cover both the code and the context around it.
Three conditions
Without Oprex MCP
• AI agent has no access to your project history.
• Every session starts from zero — no issues, requirements, or decisions.
• You paste context manually or the agent guesses.
• Re-discussing constraints from March in August.
• No traceability: the agent cannot link its change to a requirement.
With Oprex MCP
• Agent queries SDLC data via 79+ MCP tools.
• One ranked search across issues, tickets, requirements, specs, tests, milestones, notes.
• Facts and memory give the agent a recorded history to read before writing.
• Agent files issues, test cases, and release notes as it works.
• Token-efficient: one search ≈ 491 tokens vs reading the whole backlog.
With Oprex MCP + Kilo Code indexing
• Kilo Code indexes your local codebase (symbols, references, definitions).
• Oprex MCP indexes your SDLC data (issues, requirements, decisions).
• Agent has both: the code structure and the project record.
• Search spans code AND artifacts in one agent session.
• Best of both: structural code understanding + contextual SDLC knowledge.
Real examples
Example 1 — Onboarding to a legacy module
Without Oprex: You spend 30 minutes reading the auth module and old Slack threads to answer 'why is this like this?'.
With Oprex MCP: You ask once. The agent recalls the fact (with asserted date and source) in 491 tokens and starts coding.
With Oprex + Kilo indexing: The agent reads the auth module structure via Kilo indexing, recalls the decision from Oprex, and explains the constraint in one paragraph.
Example 2 — Bug that was reported before
Without Oprex: You search the issue tracker manually. You find the report, but not the reproduction steps attached to it. You reproduce it again.
With Oprex MCP: You ask the agent to search. It returns the earlier report with reproduction steps, including closed ones, ranked by relevance.
With Oprex + Kilo indexing: The agent searches both the bug report and the code path that was patched last time. It points you to the exact line and the earlier fix in one turn.
Example 3 — Releasing a change
Without Oprex: You assemble release notes by hand. You check which requirements have passing tests by opening a spreadsheet. You write the changelog.
With Oprex MCP: Release notes are generated from the release plan's scope. The coverage matrix answers 'which requirements have no passing test' continuously.
With Oprex + Kilo indexing: The agent writes the code, runs tests, checks coverage against requirements via Oprex, and drafts the release note — all before you review.
What Oprex MCP actually indexes
Oprex MCP does not read your source files. It reads the artifacts that live inside Oprex: issues, tickets, requirements, specifications, test cases, milestones, notes, and memory facts. Those are indexed with Postgres full-text search under both the Indonesian and English stemmers, plus a ranked cross-artifact search that returns the most relevant hits across every kind in a single 491-token call.
Kilo Code's code indexing works on your local files. It understands function signatures, call sites, and module boundaries inside your IDE. Oprex does not compete with that — it complements it. The agent needs both to write code that is structurally correct and consistent with the project's recorded decisions.
The token arithmetic
On a corpus of 1,363 artifacts — roughly one year of a small team's output — we measured:
| What | Cost | Note |
|---|---|---|
Tool definitions loaded once per session (tools/list) | ≈ 11,890 tok | 46.4 KB, 79 tools. Paid once per session. |
Narrowed to issues,requirements | ≈ 1,050 tok | ~91% cheaper than full load; covers bug triage + product workflows. |
Narrowed to search only | ≈ 151 tok | Single-tool session; useful for read-only lookup agents. |
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, 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. |
The break-even on token count alone is roughly 39 lookups in a single session when using the full tool surface. With tool narrowing, that break-even drops proportionally: a 2-category session pays back in roughly 3 lookups. Most sessions do not do 39 lookups. The real saving is in the work that never happens: the file you do not have to read, the bug you do not re-diagnose, the constraint you do not re-explain.
Use X-MCP-Toolsets: issues,requirements or the toolsets JSON-RPC param on tools/list to load only the tools your task needs.
Ready to try?
Connect Oprex MCP to your editor in under five minutes. Kilo Code, Claude Code, Cursor, VS Code, Gemini CLI, and ChatGPT are supported.
Set up MCP →