feat: use copy-paste instead of api

[ther0bster]

Thanks for your work on aider, it's a truly amazing open-source project!

See https://github.com/Aider-AI/aider/issues/3479

Inpired by aider's copy-paste mode and Roo-Codes's Human Relay feature, I integrated a proof-of-concept ~~--copy-paste-no-api mode~~ copy-paste without API capability into aider.

~~The --copy-paste-no-api mode allows using aider with a web ui only and without any api.~~

UPDATE: I've refactored the implementation to be more flexible and intuitive. Instead of using --copy-paste-no-api as a separate flag, you can now add the cp: prefix before any model name to use that model in copy-paste mode rather than via API. This makes it possible to mix API and copy-paste modes in the same session.

Why would anyone want to use this?

As already nicely explained in https://github.com/RooVetGit/Roo-Code/pull/1267

• aider works fully without api key
• very useful for using aider at e.g. work where
  • sending code to api / hosting local ollama model is not allowed/possible
  • but using web ui like GitHub copilot is allowed
• cost per token if often cheaper in web ui than in api
• equivalent to aider's --copy-paste mode this should not violate ToS

As this is just a quick proof-of-concept implementation, I appreciate feedback on how such a feature can fit best within aider's architecture. The code has some rough edges, e.g. passing io to Models class.

~~Also, I'm confident someone will find a better name for this than --copy-paste-no-api.~~

To test this, check out the PR's branch and run aider with:

~~aider --copy-paste-no-api --model claude-3-7-sonnet-20250219~~

Here are some examples of how to use the new cp: prefix:

Basic usage with copy-paste mode instead of API:

aider --model cp:sonnet

Architect mode with different copy-paste models:

aider --architect --model cp:sonnet --editor-model cp:haiku --weak-model cp:4o

Mix and match: copy-paste mode mixed with API:

aider --model cp:sonnet --weak-model 4o

Note: If only a main model is specified with the cp: prefix, both the editor and weak models will be automatically set to the main model in copy-paste mode, since typically a user would be using a single LLM in a web interface. If you want to use different models with different web interfaces, you can specify the editor and weak models manually as shown above.

Here is a short screen recording demonstrating this feature

https://github.com/user-attachments/assets/e83c1a81-b970-44c6-99ea-879589399ecb

[CLAassistant]

All committers have signed the CLA.

[duggthangs]

This would be a great feature. I actually requested this on Discord and someone pointed me to this repo.

@ther0bster Does this feature also support the /context mode for manual copy and pasting? (I copy and paste stuff all the time and don't want to accidentally copy something to my clipboard to be passed to Aider)

[ther0bster]

@duggthangs currently, this feature unfortunately does not support /context, /copy-context or manual copy/paste as this would require more profound architectural changes.

I will try to look into it when I find some time.

[sukima]

@ther0bster Are there any blockers for this? Is it possible to merge this for now and look into more features later?

I'm most interested in using aider with kagi.com which is WebUI only. I don't really want to force a second openrouter/free or install my own ollama yet and would like to see what a full copy/paste workflow might be like.

@duggthangs How do you use /context and /copy-context work flow now? I tried this myself and ran into issues where it mostly one way (aider -> WebUI) and the reverse (WebUI -> aider paste) didn't work so well.

[ther0bster]

@sukima this copy/paste without api feature is currently in a working proof of concept state.

you can just check out the PR branch and test it:

$ cd ~
$ git clone -b copy-paste-no-api --depth=1 https://github.com/ther0bster/aider.git
$ cd aider
$ uv sync
$ cd /to/your/code/project/folder
$ uv --project ~/aider run aider --model cp:gemini
# use aider, it will prompt you to copy & paste from web ui

this PR is awaiting feedback on how it fits within aider's architecture. basically, this works and can be merged.

there are some refinements that can be made, e.g. an option to copy the system message for the LLM separately, as some web UIs like google ai studio explicitly allow to provide a system message.

[AgarwalPragy]

This works flawlessly, thanks! 🎉

Is there anything keeping from moving this forward? Would love to contribute.

[ther0bster]

@AgarwalPragy thank you for testing the copy-paste implementation and for the feedback! still waiting for any comments from the maintainers.

[sukima]

Is this feature still blocked?

What are the blockers?

How can others help unblock this?

[sukima]

I tried to use this based on main (merged your branch onto main) and discovered a build issue:

Using CPython 3.12.10
Creating virtual environment at: .venv
  × No solution found when resolving dependencies for split (python_full_version < '3.11'):
  ╰─▶ Because the requested Python version (>=3.10, <3.13) does not satisfy Python>=3.11 and contourpy==1.3.3 depends on Python>=3.11,
      we can conclude that contourpy==1.3.3 cannot be used.
      And because aider-chat[dev] depends on contourpy==1.3.3 and your project requires aider-chat[dev], we can conclude that your
      project's requirements are unsatisfiable.

      hint: The `requires-python` value (>=3.10, <3.13) includes Python versions that are not supported by your dependencies (e.g.,
      contourpy==1.3.3 only supports >=3.11). Consider using a more restrictive `requires-python` value (like >=3.11).

This appears to be a problem on main as well, but it blocks me from trying this out locally.

Also, curious what about this feature is preventing further discourse on it from the maintainers?

[sukima]

What is blocking this feature?

Sadly at this point I will have to move on to other tools. This feature was one of the core reasons I was interested in Aider. I loved its use and worked great except this feature. And it can't be used from a a clone of this branch either (see above).

Sadly this seems to be a dead PR (dead project?).

[sukima]

Status Update and Request for Review

It's now been over 7 months since this PR was opened, with a working proof-of-concept that multiple community members have tested and confirmed functional.

Community Validation

The feedback speaks for itself:

• ✅ "This works flawlessly, thanks! 🎉" (@AgarwalPragy)
• ✅ Multiple users actively requesting this feature
• ✅ Clear use cases documented (enterprise environments, cost optimization, ToS compliance)
• ✅ Inspired by existing patterns in the ecosystem (Roo-Code's Human Relay)

The Silence is Deafening

What's particularly concerning is the complete absence of maintainer feedback:

• No architectural concerns raised
• No requested changes documented
• No timeline provided
• No acknowledgment of the multiple "what's blocking this?" inquiries

Meanwhile, interested contributors are literally asking "How can we help unblock this?" and receiving... nothing.

The Cost of Inaction

This pattern has real consequences:

1. Community attrition: Active contributors are moving to other tools (see @sukima's final comment)
2. Wasted effort: @ther0bster has done the work, refactored based on best practices, and is ready to iterate
3. Missed opportunities: Users who could benefit from aider are blocked by a solvable problem
4. Project perception: "dead PR (dead project?)" shouldn't be a question users are asking

A Simple Request

Please provide feedback. Even if the answer is "no," that's infinitely more valuable than silence. If there are concerns:

• State them clearly
• Let the community address them
• Or explain why this doesn't align with the project's direction

This PR represents exactly what open source should be: a contributor identifying a need, implementing a solution, and seeking to give back. The least it deserves is a response.

Maintainers: What would it take to move this forward?

---

Note: If there are technical blockers (like the Python dependency issue mentioned), those should be documented in the PR so contributors can address them.