archetech / archon / 29552315689

90%

Build Type

push

github

Committed by web-flow

Commit Message

feat: link large file assets instead of inlining base64 (#735) (#737)

* feat: link large file assets instead of inlining base64 (#735)

get_asset_file put the whole asset in the model's context as base64, costing
roughly bytes/3 tokens: ~350k for a 1 MB file, ~3.5M for the 10 MB a node will
accept -- more than any context window holds. Above ARCHON_MCP_INLINE_LIMIT
(16 KiB default) it now returns a resource_link, which #725/#734 made honest by
implementing the read path a link points at.

Size is read from the DID document before anything is fetched: generateFileAsset
records `bytes` next to the CID, so a linked asset never leaves the gatekeeper.
That costs small assets one extra resolve, which is the cheaper mistake --
fetching megabytes to then measure them defeats the point. MCP's `size` field
carries it, documented for hosts to "estimate context window usage".

An asset with no recorded size is linked rather than gambled on: guessing
"small" risks burying the conversation, while a needless link costs the client
one resources/read.

The limit is configurable because it doubles as the escape hatch: a client that
ignores resource links gets a link where it used to get bytes, and a very large
ARCHON_MCP_INLINE_LIMIT restores the old behaviour. 16 KiB by default because
base64 is not readable by a model -- inlining only helps a client render or save
the bytes, so it should stay cheap. The mcp-server is not in any compose file,
so the compose-default pitfall does not apply.

Images still always inline: an image block is how a model sees an image, and a
link is not something it can look at.

Handlers now receive the config, which is how the tool reads the limit.

Verified through a real client: a 2 MB asset returns an 85-token result instead
of ~700k, getFile is never called, and readResource on the link returns all
2 MB on demand.

Breaking: large file results change shape for clients that do not follow links.

Co-Authored-By: Claude Opus 4.8 (1M conte... (continued)

Coverage Stats

2970 of 3521 branches covered (84.35%)

Branch coverage included in aggregate %.

20 of 20 new or added lines in 2 files covered. (100.0%)

1 existing line in 1 file now uncovered.

6168 of 6595 relevant lines covered (93.53%)

834.84 hits per line