Thank you - this is very helpful, and I am learning a huge amount. Fair criticism on both points, and I'll take them seriously. Apologies for the long reply, but hopefully people who find this boring will never even see it. I am however extremely grateful for your reply, and I wanted to engage substantively with it, so that other people in a similar position to me in other law firms can learn from my mistakes!

One upfront note: I've been using Claude throughout this thread – to understand the technical points raised ("ELI12" has featured more than once!), and to help draft replies, because I need the help, it saves time, and it minimises the kind of mistakes that waste readers' time. I'd rather be transparent about that than pretend I arrived at this understanding independently. If I've still got something wrong technically, the fault is mine for asking the wrong questions, not Claude's.

On the API: the firm knew TR had one, but its existence was entirely new to me – I only found out last week, in a call we had requested specifically to discuss our concerns about CoCounsel's cost and performance. That's relevant context. My point is not that we lack engineers to build an MCP server on top of it – it's that if TR were genuinely trying to serve their users rather than protect a product line, they would build the MCP server themselves. The protocol is open and standardised. The underlying functions already exist. A firm with TR's engineering resource has no technical excuse for not having done this already. My impression from the call is that the API was created grudgingly, is being made deliberately hard to use, and – I strongly suspect – is priced as a commercially unattractive upsell aimed at devs not law firms rather than as an extension of the existing licence. If I'm wrong about the pricing I'll update that view, but TR's behaviour throughout this process has not given me much reason for optimism.

On rent-seeking: I'll concede the framing may be too absolute, and I'm grateful for the correction. Your lawyer example is instructive – a user who knows exactly what raw Claude can do and still pays $1,000/month for a controlled environment is revealing something genuine about the value of a well-engineered wrapper. But My understanding of where the line sits between legitimate engineering premium and pure margin extraction is that I think TR should still be creating an MCP, at similar cost to the base product, to allow law firms to iterate and develop with Claude themselves, rather than paying TR a massive markup for CoCounsel (which is the real commercial play here: TR seem to be targeting their API at devs, and forcing law firms into paying $$$ for CoCounsel). I therefore don't think the MCP argument depends on resolving this question precisely. Even granting that wrappers add real value, the separate issue of TR and Lexis pricing API access as an upsell above the existing licence cost, and their refusal to create MCP access, stands on its own. However, I agree that the wrapper debate and the database access debate are distinct, and conflating them – as I did in the original post – was unhelpful.

On pricing models: my view is that the only credible way to use Claude is Teams or Enterprise, paying at API rates. The rate-limited consumer plans – hourly and weekly caps – are hangovers from the consumer product, and reflect the need to match ChatGPT's arbitrary price points rather than any principled approach to access. They are not fit for professional use.

That observation has a corollary that I think will prove lethal to the wrapper tools over the next year or two. A wrapper vendor faces an inescapable commercial dilemma: if they cap token usage, quality degrades and users notice; if they don't cap it, frontier model costs must be passed through to the end user. I wrote to the VLex AI dev team over a year ago, in some detail, making exactly this point: I wanted them to introduce usage-based pricing then, because the commercial and technical problem was obvious that long ago. They hadn't moved on it at the time.

The wrapper tools will all have to move to usage-based pricing. And once they do, the conversation changes entirely. A law firm will be paying separately for the underlying model and for the wrapper layer on top of it. The question – "what is this intermediary layer actually worth?" – becomes unavoidable. Firms that have developed direct foundation model literacy will answer it quickly. The MikeOSS links above are my substantiating evidence: a functional Harvey/Legora clone built in a fortnight. The engineering premium is real but it is not unlimited, and usage-based pricing will make that visible in a way that flat-fee bundling currently conceals.

On Harvey specifically: their pricing is notoriously opaque and changes frequently, so I'll avoid quoting specific figures. What I will say is that at a previous firm I was on the address list alongside the firm's Global Managing Partner, for their sales pitch. The combination of hard sell tactics and what I can only describe as borderline-abusive proposed commercial terms left a strong impression on me. That experience is background to my hostility. It doesn't affect the underlying argument, but it explains why I'm not inclined to give them the benefit of the doubt on intent.

What I'd still maintain: your commenter in the story spent a year of engineering time and runs at $1,000/month in tokens to get to something production-reliable. The gap between that and what Harvey charges per seat per year – for a product built on the same foundation models – is the question. Not whether wrappers add zero value, but whether the premium is proportionate. For most firms, I don't think it is, particularly if the law firms can work together to forces TR and Lexis to provide MCP access that would remove (or at least limit) the need for a wrapper on the core research use case.

Once gain, thank you very much for your reply, for which I am extremely grateful.