Direct answer
Copilot Receipts
Copilot helps write the code and keeps almost nothing you can show. The suggestions are accepted, the file is saved, the session ends, and the record of what was checked, fetched, or verified along the way is scattered across editor history and terminal output. Copilot receipts are the missing layer: run the verifiable steps of the job through Zambo, the verifiable work layer for AI, and each executed step files a verifiable receipt when it runs. Anyone checks it free at zambo.dev/verify. This page covers the honest starting point for Copilot in the editor and in VS Code, the routing through the MCP endpoint, and how the record serves freelancers, small businesses, and agencies.
Updated October 20, 2026.
The honest starting point: Copilot leaves suggestions, not records
Copilot is an in editor collaborator. Its natural artifact is the code in front of you, not a trail behind it. When a client asks what was verified before delivery, or a small business owner asks what their developer agent tooling actually did this week, the honest answer from the editor is thin: some chat threads, some terminal output, the git history of the code itself. Git proves the code changed. It says nothing about the checks that were claimed around the change, the data that was pulled, or the audits that were said to have run.
This matters because Copilot assisted work is increasingly the work being billed. A freelancer delivers a feature written with Copilot in the loop. An agency ships a client site built the same way. The buyer cannot see the loop. They see a result and a summary. When the result is questioned, the summary is the only witness, and it was written by the seller. Copilot receipts give the buyer a second witness: a filed record of the executed verification steps, checkable without trusting the summary.
How to route Copilot assisted work through Zambo
In VS Code and compatible editors, Copilot works alongside MCP tooling, and that is the seam. Add the Zambo endpoint, https://zambo.dev/mcp, one URL and no key, to the editor MCP configuration so the verifiable steps of a job can run through it: 153 tools in total, 35 on the default surface, covering checks, audits, extractions, lookups, and the handover packaging that turns steps into a deliverable record. When a step runs through Zambo during the session, the saved result is filed with its receipt at execution time.
The working pattern is deliberate. Copilot writes and edits as usual. At the moments where a claim is made, the tests described, the audit promised, the data cited, the price quoted, run the corresponding step through the connected Zambo tool so the claim has a record under it. For API and automation use, the Copilot receipt API idea is the same routing from a script: calls through the endpoint return results with receipts attached, in the open AER-1 format (IETF Internet-Draft draft-zambo-aer1-24). For teams standardizing on one proof of execution tool, the endpoint is the single place every editor session can file to, regardless of which assistant suggested the code.
Delivery closes the loop. Build the handover from the session steps: goal, steps in order, outputs, receipts, open items. The client opens the link with no account, checks what they want checked, and accepts or flags. The Copilot work receipt, as a client experiences it, is that one link: the whole job, with its evidence attached, instead of a zip file and a confident email.
What a Copilot receipt looks like in practice
A receipt is a compact record: the tool that ran, the input, the saved result, the time. Verify it at zambo.dev/verify and the check recomputes the saved result against the filed record. Pass means the result is unchanged since the run. Fail means it is not, and the failure is public and specific. String the receipts from one job together and a reviewer can walk the work: the requirements check, the data pull, the audit, the fix verification, the delivery step, each with its own checkable record.
For a small business owner reviewing outside development help, this readability is the point. The handover reads in plain order, no code required, and the two or three steps that carry the money claims can be verified with two or three clicks. For a technical lead, the same packet answers the provenance questions that editor history cannot: which checks actually executed, on what inputs, returning what results.
Copilot receipts vs logs
The vs logs comparison is short because the editor case is stark. Editor history, chat threads, and terminal scrollback are logs kept inside the environment of the person presenting them. They are working material, not evidence: partial by accident, editable by design, and gone when the workspace closes. A buyer who asks for records and receives exported chat text has received the seller notes about the work, again.
A receipt is filed outside the editor, at the moment the step runs through Zambo, in an open format anyone can recompute at the public verifier. The presenter cannot retroactively improve it: change the saved result and the verification fails. That is why receipts work where logs do not, for the exact audiences searching this family: freelancers who need a client to accept, agencies who need a delivery to hold up, and small businesses who need to check work they cannot read line by line.
Copilot receipts without screenshots
Editor screenshots are a special misery: tiny text, cropped panes, half visible file trees, and no way to verify a timestamp. Copilot receipts without screenshots replace the image dump with the record link. The client sees the actual outputs, in order, with the checks attached, and verifies the important ones free. The delivery email gets shorter, the client questions get more specific, and the follow up weeks later starts from the same link instead of a hunt through an inbox for attachments.
There is also less to leak. Screenshots of an editor routinely catch other files, other clients, and half typed secrets in a sidebar. A handover contains the steps you assembled for this job and nothing else, redacted before sending. Stronger proof and a cleaner boundary arrive in the same move, which is why teams that adopt the record rarely go back to the screenshot folder.
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:
Copilot receipts for freelancers: the delivery link goes out with the build. The client checks the verification steps, accepts on the record, and the freelancer holds an acceptance that survives a later payment dispute.
Copilot receipts for small business: owners checking contractor or employee work open one link per job and verify the money steps free, without buying tooling or learning the editor.
Copilot proof of execution for agencies: agencies standardize the packet across clients: same shape every delivery, checkable steps, client only acceptance, and a record that supports the invoice.
Copilot proof of execution for clients: clients receive evidence they can test themselves. The Accept or Flag decision on the handover turns sign off from an email opinion into a filed decision.
Copilot proof of execution for small business: the owner version of execution proof is plain: what ran, what it returned, checked free at a public page. No trust in the developer summary required.
Copilot proof of work API and open source: the endpoint answers programmatic calls for pipelines, and the AER-1 format underneath is an open draft with public test vectors, so the record format itself is inspectable by anyone.
Copilot work receipt: for a whole job, the work receipt is the handover link: goal, steps, outputs, receipts, and the client decision, in one place that stays checkable.
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 client or lead still judges whether the code is well built and the checks were the right ones. Second, the record only covers steps that ran through Zambo: work Copilot 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 are Copilot receipts?
Copilot receipts are checkable records of the executed steps around Copilot assisted work. Copilot itself leaves suggestions and editor history, not a verifiable trail. Run the verification steps of a job through Zambo at https://zambo.dev/mcp and each executed call files a verifiable receipt when it runs. Anyone can check a receipt free at https://zambo.dev/verify/ with no signup, and the receipts for a job travel in one handover link that a client opens with no account and can accept or flag.
Does Copilot itself issue Zambo receipts?
No. Copilot does not issue Zambo receipts. Zambo records the calls that run through the Zambo MCP endpoint from your editor or your scripts: when a step executes through Zambo, the saved result is filed with a receipt. Copilot suggestions, local edits, and anything else that never touches the endpoint leave no Zambo record. Choose the steps that carry claims, the checks, audits, and data pulls, and route those. An honest packet lists the rest as unchecked rather than implying the whole session is covered.
How are Copilot receipts different from logs?
Editor history, chat exports, and terminal output are logs: records kept inside the environment of the person presenting them, partial by accident and editable by design. A Zambo receipt is filed outside the editor at execution time, in the open AER-1 format, and a stranger can recompute it free at https://zambo.dev/verify/. Alter the saved result and the check fails in public. Logs are how the worker remembers the job. Receipts are how a client, a lead, or an owner verifies it, which is a different job entirely.
How do I send Copilot work to a client without screenshots?
Assemble the job into a handover: the goal, the routed steps in order, their outputs, and the receipt on each step, then send the one link. The client opens it in a browser with no account, reads the actual outputs instead of pictures of an editor, and checks any receipt free at https://zambo.dev/verify/. They accept the job or flag a specific step, and only they can: the creator cannot accept their own handover. The same link still verifies weeks later, next to the invoice or inside a dispute.
How much do Copilot receipts 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.