---
title: "Agent artifact hosting compared: six options"
canonical_url: "https://krowk.com/compare/agent-artifact-hosting"
last_updated: "2026-09-02T08:10:22.582Z"
meta:
description: "GitHub attachments, committing to the repo, release assets, the CI artifacts tab, your own bucket and Krowk — compared on scriptability, size ceiling, link lifetime and provenance."
"og:description": "GitHub attachments, committing to the repo, release assets, the CI artifacts tab, your own bucket and Krowk — compared on scriptability, size ceiling, link lifetime and provenance."
"og:title": "Agent artifact hosting compared: six options"
---
**Comparison**
# **Where to put a screenshot an agent took**
Six options for getting evidence out of an unattended run, on the same four axes: can a script do it, how big, how long the link lives, and whether it says which commit produced the file.
[Screenshot into a PR](https://krowk.com/guides/screenshot-to-github-pr) [Read the docs](https://krowk.com/docs)
Six ways to get a file out of an unattended run and in front of a reviewer. None of them is best at everything, and the one people pick by default — the CI artifacts tab — is the one nobody opens.
Four axes decide it, and the cards below state each option against the same four in the same order, so they read across as well as down.
- **Scriptable.** Can a process with no browser and no human do it? This is the axis that eliminates the most popular option.
- **Ceiling.** How large a file, which matters the moment a screenshot becomes a screen recording.
- **Lifetime.** How long the link works. A dead link in a six-month-old pull request is worse than no link, because it looks like something was hidden.
- **Provenance.** Does the artifact say which commit produced it? Irrelevant when a person took the screenshot. Central when a model did.
## **The six options**
Every card states the same four axes in the same order.
- ### **GitHub user-attachments**
Drag the file into the comment box. The best flow here, and unavailable to a script.
- Scriptable: no — browser only
- Ceiling: 10 MB images, 25 MB other files
- Lifetime: as long as the comment
- Provenance: none
- ### **Commit it to the repository**
Scriptable through the contents API, versioned with the code, and permanent whether you want that or not.
- Scriptable: yes
- Ceiling: whatever git tolerates
- Lifetime: forever, including in every clone
- Provenance: the commit it was added in
- ### **Release assets**
The one upload endpoint GitHub documents. Hangs off a tag, downloads rather than renders.
- Scriptable: yes
- Ceiling: no fixed number published
- Lifetime: as long as the release
- Provenance: the tag, not the commit
- ### **CI artifacts tab**
Free, already configured, and three clicks from the diff — which is why nobody opens it.
- Scriptable: yes
- Ceiling: your plan's storage quota
- Lifetime: 90 days by default, then gone
- Provenance: the run, if you go looking
- ### **Your own bucket**
S3 or R2 with a public prefix. Cheapest per byte; the setup is the part that does not happen.
- Scriptable: yes
- Ceiling: yours
- Lifetime: yours, via a lifecycle rule
- Provenance: none — a raw blob URL
- ### **Krowk**
One command, a permalink, and a preview page carrying the run behind the file.
- Scriptable: yes, and keyless on the first push
- Ceiling: 100 MB free, 2 GB on Pro
- Lifetime: 24 hours free, permanent once claimed
- Provenance: repo, commit, branch, agent, model
## What the table does not settle
If the file has to be readable from a clone in five years, commit it and accept the history. Every hosted option, this one included, is a link that outlives the service by exactly zero days.
If a human is already in the browser, drag it into the comment. GitHub hosts it free, permanently, on a domain the organisation already trusts, and no tool beats that.
The rest of the table is for the case where the thing holding the file is a process. There the question stops being where to put the bytes and becomes whether the reviewer can tell what they are looking at — which is why provenance is on the list at all.
## Disclosure
Krowk publishes this page, so read the Krowk column with that in mind. The numbers in the other columns come from each tool's own documentation, and the rows where Krowk loses are on the page for the same reason the rest are: a comparison that never loses is not one anybody should cite.
**FAQ**
## **Which tool, and why**
What is the best way for an AI agent to share a screenshot?
If a person is at a browser, drag it into the comment — GitHub hosts it free and permanently. If the thing holding the file is a process, it needs a command: either write to your own bucket and accept a raw blob URL, or use a host that returns a link which renders. The axis that usually decides it is provenance — whether the artifact states which commit produced it, which matters when a model took the screenshot rather than a person.
Why is the CI artifacts tab not the answer?
It works and it costs nothing. It is also a zip file three clicks from the diff, and the review happens in the diff. The artifact that gets looked at is the one already rendered in the thread.
Do any of these keep working forever?
Committing to the repository does, at the cost of carrying the bytes in history in every clone. Everything else is a hosted link that lives as long as its host — including Krowk, whose free links expire after 24 hours and whose claimed links last as long as the service.
## **The narrow one, if provenance is what you are missing.**
One command, a permalink, and a card that names the commit behind the picture. Free to try, and no account for the first push.
[Read the docs](https://krowk.com/docs) [See the pricing](https://krowk.com/pricing)