initial take on anthropic docs api

[georgeharker]

I have not yet added tests or README updates.

I had need of this myself.

Just curious on interest here - I had code companion do the bulk of the work with guidance. It looks pretty much in line with how images and files work.

Description

This adds a slash command (/document) to attach doc types like docx, pdf, rtf which allows anthropic users to pass files directly through the adapter.

Related Issue(s)

#2216

Checklist

• I've read the contributing guidelines and have adhered to them in this PR
• I've run make all to ensure docs are generated, tests pass and StyLua has formatted my code
• (optional) I've added test coverage for this fix/feature
• (optional) I've updated the README and/or relevant docs pages

[olimorris]

Hey George. It's like you read my mind....I was giving this some serious thought earlier today.

Normally, I'd try and add a feature like this to all http adapters but given the enormity of that as a task, I'd rather we get something like this into CodeCompanion.

Let me know when you're happy with it and I can take a look later down the line. In the same way I restrict the image slash command by looking for adapter.opts.vision, via the config, I think we should add file (or whatever Anthropic call it) to the Anthropic adapter. Not sure if any of that makes sense....long day!

[georgeharker]

great! I've updated to check for doc_upload capabilities rather than vision.

Added some docs.

I'm actually not sure what other adapters support pdf / docx and i'm sure there's possibly some differences in implementation. I'm pretty sure that opencode and copilot don't properly proxy these requests to models even with an anthropic model requested, though they appear to read pdfs just fine using their inbuilt tools.

[olimorris]

One reflection I had was "as a user, should I be expected to know the difference between /file and /document?" I'm cool with keeping document and file as separate classes, just think it makes the UX cleaner. If a user tries to send a PDF to an OpenAI adapter if we've set opts.files = false or it comes back as nil, we could just alert the user that this isn't supported yet.

[georgeharker]

I was thinking about that too.

I’ll try and tidy that up.

It also looks like acp can ingest embedded files similar to how it does for images so working on that.

[olimorris]

It also looks like acp can ingest embedded files similar to how it does for images so working on that.

That's good to know. I have a feeling how I'm sharing files with ACP agents may not be correct. I can take a look at that too.

[georgeharker]

One reflection I had was "as a user, should I be expected to know the difference between /file and /document?" I'm cool with keeping document and file as separate classes, just think it makes the UX cleaner. If a user tries to send a PDF to an OpenAI adapter if we've set opts.files = false or it comes back as nil, we could just alert the user that this isn't supported yet.

I guess one issue is that /document allows attaching from remote URLs or using file_api if enabled. I'll def tidy that portion up so you can look. I do like the idea of a unified interface for sure, just not sure how to include URL and file api support to /file

[olimorris]

We could always take the logic that I put in the /image slash command where the user is asked to select a URL or a file beforehand. That feels like a reasonable compromise to keep everything within one slash command.

[georgeharker]

That’s what I did for document. I’m concerned that for folks used to /file just giving a picker it would now present and additional choice first. Maybe that’s not a big deal

[georgeharker]

I'm happy to look at merging /file and /document. Couple of options before I do that

1. I think merging implementations might be sensible given there's duplication between image and document at least
2. Should /document be kept separate but called /attachment - /file approximately means /textfile (not suggesting altering that) but maybe there are useful destinctions. We could even have /attachment deal with text files - optionally fetched from a URL, but keep /file to be strictly local text file
3. alternatively should /document be rolled into /file - in which case it would present a url or file dialog first, which seems like it might be irritating for current use cases.

[georgeharker]

I guess finally there's the option of /image and /document being merged (possibly into /attachment)

Lmk, and I can look at getting it done