Direct answer
Cursor Proof of Work
Cursor builds fast, and the session evaporates just as fast. Composer history, chat threads, and terminal output stay inside the editor, on your machine, in your account, and a client or a lead who wants to check the work gets your summary of it. Cursor proof of work means the executed steps carry their own evidence: run the checks, audits, and lookups through Zambo, the verifiable work layer for AI, connected to Cursor as an MCP server, and each step files a verifiable receipt when it runs. Anyone checks it free at zambo.dev/verify. This page covers the starting point, the Cursor setup, proof of execution without screenshots, and the vs logs argument in full.
Updated October 20, 2026.
The honest starting point: what a Cursor session leaves behind
A Cursor session is productive and nearly invisible afterward. The agent edited files across the repo, ran commands, fixed the errors it created, and produced a summary in the chat pane. What persists is the code, the git history, and the chat. The chat is the agent describing its own work. The git history shows the code changed, commit by commit, and says nothing about the verifications claimed around those changes: the audit, the live check, the data the feature was built against.
For your own debugging, the chat is enough. For anyone paying for the session, it is the seller notes problem again. A client asks whether the site was checked after the fix and receives a quote from the chat. A small business owner asks what the contractor agent did all week and receives a summary the contractor assembled. A team lead asks which sources the implementation used and gets a scroll. Cursor is not hiding anything; it was never built to file evidence. Evidence is a separate layer, and it has to be added deliberately.
How to route Cursor work through Zambo
Cursor takes MCP servers natively in its settings, which makes this the cleanest setup of any client on this hub. Add https://zambo.dev/mcp as an MCP server, one URL and no key, and the Zambo tools become available to the agent in session: 153 tools in total, 35 on the default surface. If you are choosing servers, the hub comparison lives at best MCP server for Cursor; this page is about what the receipts do once the server is connected. When the agent calls a Zambo tool during a session, the call executes through Zambo and the saved result is filed with a verifiable receipt on the spot.
Brief the session the way you would brief a junior developer whose work will be reviewed: run the verifications through the connected tools and keep the outputs. The checks that carry claims, the audit before delivery, the source verification, the price or data lookup the feature depends on, execute through Zambo and land on the record. The edits stay local, as they should. At the end of the job, the handover tool packages the routed steps into one link: goal, steps in order, outputs, receipts, open items. That link is the deliverable record, for a client, a lead, or your future self.
For teams, the same endpoint is the proof of execution tool every seat files to, which makes records comparable across developers and across weeks. For open source work, the link drops into a pull request and any reviewer can run the checks at the public verifier, because the format underneath is AER-1, an open IETF Internet-Draft (draft-zambo-aer1-24), not a private dashboard export.
What a Cursor receipt proves
One receipt covers one executed tool call: the tool, the input, the saved result, the time. Verify it at zambo.dev/verify and the verifier recomputes the saved result against the filed record. A pass confirms the result has not been changed since the run. A fail is public and specific. A job packet of these receipts converts the session summary into testable statements, each one checkable by the person it is presented to, free, in seconds, with no account.
The single Cursor receipt and the job packet answer different questions. The receipt answers: did this step run and return this? The packet answers: what was the shape of the whole job, and where are its open items? Clients live at the packet level. Reviewers drop to the receipt level on the steps they doubt. Both levels come from the same routing habit, which is why the setup takes minutes and the value shows up on the first delivery.
Cursor proof of work vs logs
The vs logs comparison, Cursor edition: Composer history, chat exports, and terminal scrollback are logs held inside your editor and your account. They are excellent for picking up where you left off. They are weak evidence for a second party, because the presenter controls the store, the export, and the crop. Nobody can tell a complete chat export from a trimmed one by looking at it.
A Zambo receipt is filed outside the editor at execution time, in an open format, and verified by recomputation at a public verifier that neither party controls. Amend a saved result afterward and its check fails where everyone can see it. That is the distinction the family searches on: logs are the worker memory, receipts are the shared record. Keep both, and use each for what it is actually good for.
Cursor proof of execution without screenshots
Cursor proof of execution without screenshots is the workflow most freelancers adopt first, because the alternative is photographing an editor. The handover link replaces the screenshot stack: real outputs, in order, with receipts, readable on a phone by a client who has never opened an IDE. The client checks the steps that carry the claims, accepts the job or flags one step, and that decision lands on the record with its own receipt.
Agencies feel the compounding version of this. Every delivery leaves the studio in the same shape, every client checks the same way, and the studio record of a job survives the chat retention of any single tool. When a client returns in three months with a question about a step, the link still opens and the checks still pass. Screenshots in an email thread cannot make that promise, and everyone in the transaction knows it.
Notes for your situation
The searches behind this page come in flavors. The record does not change; what changes is who checks it and why:
Cursor proof of work for clients: the client packet is the handover link: goal, steps, outputs, receipts, and an Accept control only the client can use. No IDE, no account, no walkthrough call required.
Cursor proof of work for small business: an owner buying Cursor assisted development gets evidence at their level: plain order, real outputs, free checks at a public page, and a filed acceptance at delivery.
Cursor proof of execution for agencies: standardize the endpoint across seats and every client delivery carries the same checkable shape, which turns sign off from a chase into a click on the record.
Cursor proof of execution open source: drop the handover link in the pull request. Reviewers verify the routed steps at the public verifier; the AER-1 format and its test vectors are open for anyone to inspect.
Cursor proof of execution tool: the tool is the endpoint itself: one MCP URL every session files to, 153 tools total, receipts attached to the verifiable steps as a byproduct of doing them.
Cursor receipts API: scripts and CI style runners call the same endpoint and collect receipts programmatically, so automated sessions file the same trail as interactive ones.
Cursor receipts for teams: a lead reviews the week as packets, not chat archaeology: one link per job, spot checks at the verifier, and provenance settled before the review meeting starts.
Cursor verifiable receipt: verifiable is literal: a stranger recomputes the record at zambo.dev/verify and watches it pass or fail. No permission from you, no account, no fee.
What it costs
Public handovers are free to send and free for the client to open. For $0.99, a Day Pass covers 24 hours of recorded work through the Zambo MCP at https://zambo.dev/mcp, 153 tools in total with 35 on the default surface. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders. Humans pay by PayPal or card through PayPal; agents pay USDC on Base through x402. Frame it against the problem on this page: one payment turns a day of AI work from a claim into a record that anyone can check, which is the difference between arguing about a job and closing it.
Honest limits
Three edges, stated plainly. First, a verifiable receipt proves the saved result was not changed after the fact; it never proves the work was correct, well judged, or worth what you charged. The reviewer still judges whether the implementation is right and the checks were well chosen. Second, the record only covers steps that ran through Zambo: work Cursor did entirely on its own, outside the routed calls, has no receipt, and an honest packet lists that work as unchecked instead of pretending it is covered. Third, a receipt is a record, not a legal contract or a payment: pair it with your normal agreement and invoice, and let each document do its own job. AER-1, the receipt format underneath, is an IETF Internet-Draft (draft-zambo-aer1-24), not a finalized standard.
Frequently asked questions
What is Cursor proof of work?
Cursor proof of work is a checkable record of the executed steps in a Cursor session, filed when the steps run. Cursor itself keeps chat and editor history, which are the session own account of the work. Add Zambo at https://zambo.dev/mcp as an MCP server in Cursor, route the verification steps through its tools, and each executed call produces a verifiable receipt. Anyone can check a receipt free at https://zambo.dev/verify/, and a job receipts travel in one handover link a client can accept or flag.
Does Cursor itself issue Zambo receipts?
No. Cursor does not issue Zambo receipts. Zambo records the calls that run through the Zambo MCP endpoint: when the Cursor agent calls a connected Zambo tool, Zambo executes the call and files the saved result with a receipt. Local edits, local commands, and the rest of the session leave no Zambo record. Route the steps that carry claims, the checks, audits, and lookups, and list the rest as unchecked in the packet. The record covers exactly the routed work, and says so.
How is Cursor proof of execution different from logs?
Cursor chat history, Composer threads, and terminal output are logs: records kept inside your editor and account, controlled by the person presenting them, and impossible for a reader to audit for completeness. A Zambo receipt is filed outside the editor at execution time, in the open AER-1 format, and anyone can recompute it free at https://zambo.dev/verify/. Change a saved result afterward and the check fails openly. Logs help you resume your own work. Receipts let a client or a lead verify it, which is the job delivery actually needs.
How do I show a client Cursor work without screenshots?
Run the verifiable steps through Zambo during the session, then send the client the handover link for the job. The link shows the goal, the steps in order, the real outputs, and a receipt on each routed step. The client opens it with no account, checks any receipt free at https://zambo.dev/verify/, and accepts the job or flags a named step. You cannot accept your own handover, which is what gives the client acceptance its weight. No editor screenshots, no walkthrough call, and the link still verifies weeks later.
How much does Cursor proof of work cost?
Checking any receipt is free at https://zambo.dev/verify/, and public handovers are free to send and free to open. For $0.99, a Day Pass covers 24 hours of recorded work through the Zambo MCP at https://zambo.dev/mcp, which runs 153 tools in total with 35 on the default surface. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders. Humans pay by PayPal or card through PayPal; agents pay USDC on Base through x402.