Sena

Your assumption in question 1 is right and it is the whole answer.

An agent turn is not one request. It is a loop: read files, call a tool, get output, decide again. Every step re-sends the accumulated conversation, so cost grows with the square of the session length rather than in proportion to it. A session that ran forty tool calls did not cost forty times a single call — it cost considerably more.

What that means practically is that the expensive sessions are almost never the ambitious ones. They are the ones that went in circles: a failing test the agent kept re-reading, a large file pulled into context early and carried for the rest of the run, a loop of edit-and-check that never converged. The work product looks small, which is exactly why nobody suspects it.

So the metric you want is not cost per session. It is cost per session divided by whether anything got merged.

It changes it a lot, and it is the reason two teams with identical usage can get very different bills.

Re-sending a prefix that has not changed can be billed at a fraction of the normal rate, so a session that keeps a stable context is dramatically cheaper than one that keeps disturbing it. The thing that ruins it is anything that mutates the early part of the conversation — an injected timestamp, a reordered file list, a tool that rewrites its own instructions.

So "did the cache hit" is a genuinely useful number and it is one of the few where a tracking tool earns its place. It is also the number you can act on: the fix is usually a small change to how context is assembled, not a change of model.

Your first habit is the best one and I would push it further: what people say they came from is not just the most reliable signal on the page, it is often the only real content on it.

"I was using X and switched" tells you the category the tool is really competing in, which is frequently not the category it claims. A thing marketed as a workflow platform whose reviewers all came from a note-taking app is a note-taking app. That is genuinely useful and no amount of star ratings would have told you.

Two more that have held up for me:

Does the description say what it does not do. Anything honest has a boundary. A page where everything is a strength was written by somebody who has not used it under load, or who is hiding the boundary, and you will find it in week two.

Is there a version number or a changelog. Not for the version itself — for the evidence that this is the eleventh thing they shipped rather than the first. A maker who has been iterating in public for a year is a much better bet than an identical tool that appeared fully formed last Tuesday.

Question 1 is the one to lead with, and there is a clean test for it.

Ask whether it drives a real terminal — an actual pseudo-terminal running the same binary you would run yourself — or whether it talks to an API and renders its own view. Both exist in this batch and they behave completely differently the moment something is unusual.

A real terminal underneath means anything that works in your shell works there: your config, your environment, your credential helper, the odd prompt that expects a keypress. A reimplementation means a curated subset, and you find the edges by hitting them at the worst moment — usually an interactive prompt the wrapper cannot forward, leaving the session wedged with no way to answer it.

The wrappers that describe themselves in terms of real terminals and session resume are telling you which kind they are. That language is a deliberate signal to people who have been bitten.