This is the next how-to guide in the series. The earlier guides focused on auditability for banks and enterprise teams. This one is for Cursor users: solo developers and small teams who watch the usage meter climb and cannot say where the spend went.
The hook is MCP. Cursor supports Model Context Protocol servers, and ZizkaDB ships one, so connecting it takes about 30 seconds and requires no changes to how you work. Once it is connected, the same event record that gives enterprises an audit trail gives you a breakdown of token cost by model, session, and step, and a way to cut it based on your actual usage.
Part 1: Connect ZizkaDB to Cursor What you need Cursor, with MCP support. uv, which provides uvx. If you do not have it: bash curl -LsSf https://astral.sh/uv/install.sh | sh One of two ZizkaDB options: the managed cloud at db.zizka.ai, or the open source self-hosted stack. Self-hosting needs Docker. Option A: Self-hosted (open source, data stays on your machine)
Start the stack with the quickstart script. The first image pull may take 5 to 10 minutes.
bash curl -fsSL https://raw.githubusercontent.com/Zizka-ai/ZizkaDB/main/scripts/quickstart-remote.sh | bash
Prefer to clone the repo? Use this instead:
bash git clone https://github.com/Zizka-ai/ZizkaDB.git && cd ZizkaDB bash scripts/setup-local.sh
When it is running, the API is at http://localhost:8000 and the dashboard is at http://localhost:3001/login.
Now add this to ~/.cursor/mcp.json for all projects, or .cursor/mcp.json inside a single project:
json { “mcpServers”: { “zizkadb”: { “command”: “uvx”, “args”: [“zizkadb-mcp”], “env”: { “ZIZKADB_HOST”: “http://localhost:8000" } } } }
On localhost no API key is needed, because a dev key is injected automatically. If you changed DEV_API_KEY in infra/.env, the MCP server’s key must match it.
Option B: Managed cloud Sign up at db.zizka.ai. In the dashboard, create an agent (for example cursor-agent) and copy the API key. It is shown only once. Paste this into ~/.cursor/mcp.json or .cursor/mcp.json: json { “mcpServers”: { “zizkadb”: { “command”: “uvx”, “args”: [“zizkadb-mcp”], “env”: { “ZIZKADB_API_KEY”: “zizkadb_live_xxxx” } } } }
Two details from the README matter here. Signing up alone does not log anything, because you must create an agent and key and put the key in ZIZKADB_API_KEY. And the agent name must match: if your key belongs to cursor-agent, log events with agent=”cursor-agent”. If you use many agent names, create a tenant-wide key in Settings.
Reload and verify Reload MCP in Cursor, or restart it. Open Cursor’s MCP settings and confirm the zizkadb server shows as connected, with its tools listed. Run a short Agent prompt, then check the dashboard. Events should appear within seconds.
If you want to test ZizkaDB before involving Cursor, run pip install zizkadb-sdk && zizkadb demo. It logs a small example chain, so you can confirm the stack works first.
Two honest notes on what gets captured
MCP is called by the agent. The README refers to log_event calls, which means events reach ZizkaDB when Cursor’s agent calls the ZizkaDB tools. It is not a passive recorder of everything Cursor does. If your sessions are empty, check whether the agent is actually calling the tool, and consider adding a Cursor rule that tells it to log. The repository includes a .cursor folder and an AGENTS.md that show how the maintainers do this.
Token counts only exist if they are logged. Cost analysis depends on the model name and token counts appearing in the event data. Check one real event in the dashboard and confirm it has both. If counts are estimated or missing, treat any cost numbers as approximate, and compare them with Cursor’s own usage page.
Privacy
Self-hosted means prompts and code context stay in your own Postgres. On the managed cloud they go to db.zizka.ai. Either way, keep API keys and credentials out of prompts and rules files, because logged content is stored. You can opt out of the anonymous install ping with export ZIZKADB_TELEMETRY=false, which also works as an env entry in the MCP config.
Part 2: Cut your Cursor costs
The integration only takes minutes. The savings come from what you do with the data.
Step 1: Work normally for one week to set a baseline
Do not optimize on day one. At the end of the week, record total tokens and estimated cost, the split by model, the split of input versus output tokens, average cost per session, and your ten most expensive sessions. Without a baseline you cannot prove any change helped.
Step 2: Break the cost down by model
Rank models by spend, then ask what share of each model’s spend needed that model. A common Cursor pattern is leaving a premium model selected for everything, including renames, boilerplate, and explaining a function. Sort spend into three types: necessary (hard reasoning, big refactors), discretionary (a cheaper model would do), and wasteful (retries and loops).
Judge by cost per completed task, not cost per call. A cheaper model that needs three attempts can cost more than a premium model that succeeds once. Also check whether Max mode or large context settings are driving up the cost of each call.
Step 3: Find the outlier sessions
A few sessions usually account for a large share of spend. Open the top ten with Session Replay and look for these causes:
Context bloat: a long thread that resends a growing history on every turn. Heavy attachments: @-mentioning whole folders when a few functions were relevant. Agent retry loops: the agent repeats a failing test or command many times. Wandering sessions: an unclear goal that leads to dozens of exploratory steps. Verbose output: whole files regenerated for small changes. Rules and MCP overhead: long rules files and many MCP servers add instructions and tool descriptions to every request.
For expensive steps where the cause is not obvious, use zizkadb why or db.why() to see what inputs led to the call. It often reveals that a tool returned far more text than you expected.
Step 4: Separate input cost from output cost
If input dominates, your problem is context. If output dominates, the model is writing too much. Agent style coding is usually input heavy, so context management tends to be the biggest lever. Prompt caching can reduce the cost of repeated context on some models and plans, but verify that before counting on it.
Step 5: Apply one fix at a time Route by difficulty: a cheaper model for simple edits and questions, the premium model for hard reasoning. Start fresh chats when a task is done, with a short note carrying over any state you need. Narrow the context to specific files, functions, or line ranges. Trim your rules: keep them short and move rarely needed guidance out of always-on rules. Prune MCP servers you are not using in this project. Stop loops early: interrupt, fix the underlying error, or rephrase the task. Ask for diffs, not rewrites. Plan first with a cheap model on larger tasks, so the expensive one does not wander. Step 6: Re-measure, and watch quality too
After a week, compare against your baseline: total cost, cost per session, share of spend on the premium model, and number of retry loops. If a cheaper model causes more rework or failed tests, the saving is false, so track completed tasks and time spent fixing output as well.
Step 7: Use drift detection to catch cost regressions
Drift is useful for cost as well as safety. If a new rule, a newly added MCP server, or a model switch leads to more LLM calls per session or more retries, the drift view shows which events and transitions moved. A rise in llm_start and tool_start against your baseline is an early sign something is burning tokens. In the API this is db.baseline(). Drift shows that behavior changed, not whether it is good, so confirm with cost per session.
Step 8: Make it a ten minute weekly habit
Review the cost breakdown at a fixed time each week, set a soft budget, and look at the top three sessions whenever you exceed it. For small teams, review per project to share efficient habits, not to police anyone. Revisit your model routing rule monthly, since new models and price changes shift the trade-offs.
What the business case looks like
These figures are modeled assumptions, not measured results. Replace them with your own pricing and usage.
Take a team of 4 developers spending about 150 euro each per month, so 600 euro in total. Suppose the breakdown shows 30 percent of spend is discretionary work on a premium model and 10 percent is waste from loops and context bloat. Routing discretionary work to a cheaper model might cut that portion by half to two thirds, saving 10 to 20 percent of the total. Stopping loops and trimming context might remove half the waste, saving about 5 percent. Together that is 15 to 25 percent, or roughly 90 to 150 euro a month.
Time often matters more. If each developer loses 2 fewer hours a month to stalled or looping sessions, at 60 euro per hour, that is 480 euro a month across the team. For a solo developer on 150 euro a month, the same percentages mean 20 to 40 euro, which is modest, but you stop being surprised by the bill and learn which habits cost money.
Self-hosting is free under AGPL-3.0, and the MCP server is MIT licensed. The managed cloud is listed at 29 euro a month for Pro and 69 euro for Team, so at small usage the cloud fee can exceed the savings. For solo developers, self-hosting is usually the better fit.
Common mistakes to avoid
Skipping the verification step. An empty dashboard usually means the agent never called the tool, or the agent name does not match the key.
Optimizing without a baseline. You cannot prove a saving you did not measure.
Judging by cost per call. Cost per completed task is the number that matters.
Downgrading models blindly. A cheaper model that causes rework can cost more overall.
Changing five things at once. You will not know which change helped.
Logging secrets. Keep credentials out of prompts and rules, since logged content is stored.
Where to go from here
Paste the config, reload MCP, run one prompt, and confirm an event appears. That takes minutes. Then work normally for a week and open your ten most expensive sessions. The record you build for cost analysis is also the foundation for replay, lineage, and drift, so if your needs grow from cost control to auditability, nothing is wasted.
If you tell me which models you use in Cursor and what you spend per month, I can help you draft a model routing rule and estimate the savings for your case.
Want to test ZizkaDB with Cursor? Try our open source version here: https://github.com/ZIZKA-AI-SL/ZizkaDB
Interested in a design partnership? Fill in the form on our site or reach me directly at founder@zizka.ai
Sources: ZizkaDB repository README · zizkadb-mcp README
Top comments (0)