Every time I've wired an AI companion up to a model, the same bill shows up somewhere: a per-token API key, a cloud sandbox rental, or a second app you have to keep running. I don't like any of those options. So in Ankita 2.6.0, I tried a different one — the companion talks to ChatGPT through your already-open Chrome tab. No API key. No per-token meter running on my side. Your ChatGPT account, your plan, your limits.
That sounds almost too cheap to work, so let me show you exactly how it works and where I'm not sure it's right.
The ChatGPT Browser provider
The new provider (docs: docs/guides/chatgpt-browser.md) sends messages and attachments from Ankita into your selected, already-open Chrome conversation, then reads the correlated public replies back into Ankita. The current model stays selected; ordinary chat needs no API chat key and no separate "Chat On Steroids" application running in the background. Your ChatGPT account's availability and limits still apply — I'm not pretending the cost disappears, just that it moves to the account you already pay for.
Three things in the implementation actually surprised me by how careful they had to be:
Correlated replies, not screen scraping. A reply in the tab has to be matched back to the message Ankita sent. "Repeating Observe keeps the selected chat's original custody" — selection changes and Send admission serialize, and unresolved replies or an unconfirmed Stop can't be stranded by switching chats mid-flow. There's a real state machine behind this, not a DOM grab.
Retry durability. Native calls inside one ChatGPT reply used to conflict just because the provider reused a generation root or RPC number. Now exact retries return their durable result, and accepted work keeps its real outcome after an HTTP disconnect. Encrypted restart and an explicit Resume read the original reply without replaying its question.
Stop actually stops. The owned Stop terminates owned commands and helpers, releases the pointer, and — importantly — keeps Chrome and your apps open. Killing the browser window to stop a task is a failure mode, not a feature.
The tunnels: Core, Desktop, Plugins
Alongside the browser provider, v2.6.0 adds native ChatGPT tools: separate Core, Desktop and Plugins MCP connections that expose Ankita's workspace tools, task browsers, connected computer controls and enabled external plugins through dedicated OpenAI tunnels. Each active group needs a dedicated tunnel; Core can't mutate global connection settings, and active groups can't reuse a tunnel ID. Saved pairing and tunnel keys live in secure device storage.
This is where the approval design bites again (if you read my 4-tier approval gate piece, you know the heuristic can suggest but never deny). The provider flow ran its full verification — packaged lifecycle plus a real ChatGPT file/edit/read/command/wait flow — with zero approval cards and zero errors. I'm proud of the mechanics, and I keep going back and forth on whether zero is the right number.
Computer use arrives via the Cua driver
Windows computer use also ships in this release: connect the existing Cua driver from Plugins, and Ankita can act on your Windows screen. You see an animated pointer during actions, you can toggle its visibility, and Stop releases the pointer. Desktop computer actions follow the existing direct-action policy. One detail I had to get right: the owned pointer retains its layer across native popup menus — a pointer that disappears the moment a context menu opens is a lie about who's in control.
Strict driver discovery plus named pointer sessions initialize correctly without silently reviving a stopped session. A stopped thing staying stopped is a feature.
Skill authoring and the unglamorous stuff
Less headline-y but, I suspect, more durable: offline golden fixtures for skills, an executable author handbook, and interactive/offline scaffolding so contributors can build skills without a live environment. Plus searchable terminal/desktop cheat sheets, measured skill/MCP startup timings, schedule templates, and protected operator runbooks.
The serial suite passed 1,344 tests with zero failures and one existing skip.
The limits I'm honest about
One browser conversation/teammate/workspace at a time. Unknown page layouts and missing exact native ownership can remain unconfirmed. Additional helper platforms and independent publisher scanning are still unverified. The exact hosted, fixture, packaging and suite evidence is in the verification record (docs/chatgpt-browser-verification.md) in the repo, which I'd rather point you at than summarize.
The question I can't settle myself
Here's the design decision I'd actually like to argue about. The ChatGPT Browser provider treats your own browser tab as a provider — a first-class way to reach a model. But a tab is not an API contract. Page layouts change, element ownership gets weird, and "unknown page layouts... can remain unconfirmed" is doing a lot of quiet work in that sentence.
So: is routing through your own ChatGPT tab a legitimate provider architecture, or is it a scraper with manners — one layout redesign away from breaking? The alternative is what everyone else does: stable API, per-token pricing, key management, the whole toll booth. I chose the tab because it makes the companion free-to-run in a way an API key never can. But "free" and "fragile" share a lot of territory.
Which would you build — the pinned, priced API contract, or the tab you already have open?
Ankita is my open-source desktop AI companion — local-first, MIT, your models. The full v2.6.0 release notes: https://github.com/akyourowngames/A.N.K.I.T.A/releases/tag/v2.6.0. Tell me where you'd put the line: I'm genuinely split on the tab-vs-API question, and I'd rather hear it argued.
Top comments (0)