github copilot's route choice
Categories:
From February to July last year, copilot was freely usable in vscode insider. During this period, I witnessed the gradual decline of copilot’s agent capabilities. Hard to imagine, the first month preview of copilot turned out to be the best in effect, and then the agent capability gradually declined. What exactly changed? It is the development evolution direction of copilot. Over the past year or more, it has been “saving tokens”. In the early days, agents from all vendors would read the entire file at once—qwen cli, claudecode, gemini, and early copilot all did this. The effect was very good, except the token consumption was estimated to be somewhat large, and the context would fill up quickly; if the context was rebuilt, the cache hit rate would drop. Later, everyone moved toward fragment-based reading: some would grep and then read a few dozen lines above and below, reading more if insufficient; others used structured code tools like LSP to read. Copilot’s agent reads files from top to bottom, 50 lines at a time, occasionally 200 lines, but always from top to bottom. Combined with the default limit of 50 tool calls and an input context of less than 200k, the work it can complete is fairly limited. In the early days, all vendors’ services were operating at a loss, expecting to capture the ecosystem at low prices and figure out how to reduce costs later. But over this year or more, they finally realized costs cannot be reduced—forcing cost reduction would turn their product into a third-rate one. So there’s no need to blame copilot too much. All agents that made it to the table already charge by token, and copilot is just a lagging one. After shedding the historical burden of per-use billing, I hope copilot improves its agent and catches up with the main force, since it is still the best integrated with vscode. AI tools can be expensive, but they shouldn’t be too weak.
