Lanes Link vs Composio

Composio is one of the most complete tool layers an agent can call: over 1,300 toolkits, managed OAuth so you skip registering your own clients, sandboxed execution, triggers, and just-in-time tool search so a model is not handed a thousand schemas at once. Point a client at Composio Connect and you have working, authenticated tools in a single command.

Lanes Link is a smaller idea, deliberately. It is one MCP endpoint you run yourself, holding your accounts, your memory, your skills, and your secrets behind one policy and one audit log. The question this page is really about is custody: whose infrastructure your tokens sit on, and whose runtime decides what an agent may do with them.

At a glance

Dimension	Lanes Link	Composio
Who runs it	You, on your machine or your own cloud	Composio's cloud. Self-hosting is an Enterprise arrangement
Open source	Apache-2.0, and it is the endpoint itself	MIT, but the public repo is the SDKs and CLI. The runtime is theirs
Where credentials sit	Your machine or your bucket	Composio's cloud, encrypted at rest. Enterprise KMS proxy keeps them ciphertext-only to Composio
Coverage	Google, iCloud, Notion, and Linear today	Over 1,300 toolkits
Work and personal	A required `profile` argument on every call	Multi-account with aliases. Explicit selection is opt-in; otherwise the most recently connected account is used
Audit	One append-only, hash-chained record per call, on your storage	A queryable tool-execution log API, with rich per-call fields. Retention varies by plan
Beyond dispatch	Memory, skills, and a secret vault behind the same boundary	Sandboxed execution, triggers, parallel calls, and tool search
Billing	None. It is software you run	A free tier that covers a lot of individual use, then per tool call
Docs	lanes.sh/docs/link	docs.composio.dev

Where Lanes Link fits

Lanes Link is for people who want the boundary to be theirs. The endpoint runs on your machine or in your own cloud project, the tokens sit in your storage, and the audit log is a set of objects you own. Nothing about your accounts is a thing you have to trust a vendor with, because there is no vendor in the path.

That ownership is also what makes the owner layer possible. Memory, skills, and the vault serve without any credential at all, so an endpoint with nothing connected is already useful, and what your agent knows about you never becomes someone else's dataset. Profiles round it out: work and personal share no configuration, no state, and no credentials, and every call names which world it acts within rather than relying on an ambient default.

Where Composio fits

If you want breadth, Composio wins and it is not close. Over 1,300 toolkits against a handful is the difference between "your tool is supported" and "you are waiting for a provider to land." Composio also runs the OAuth applications for you, so you can skip registering a client with each vendor, and it handles the parts nobody enjoys: refresh, retries, and the long tail of API quirks.

Its free tier is genuinely generous for one person, so cost is not the argument against it. Neither is capability: sandboxed execution, triggers, parallel tool calls, and tool search are real engineering that a self-hosted personal endpoint does not attempt.

Worth being clear about design intent, because it is easy to compare the wrong product. Composio's primary API is shaped around your end users, not you: you create a session for a user_id, white-label the connection page your users see, and pay per connection. It is built for a developer shipping integrations inside a product they sell. Composio Connect is the individual-facing path, and it is the fair thing to weigh against Lanes Link. If you are embedding integrations into something you ship to customers, that is Composio's job and not Lanes Link's, and no amount of self-hosting changes it.

How Lanes Link does it

The endpoint is the open-source artifact. Apache-2.0, and running it yourself is the intended path rather than an enterprise tier. Providers are additive, and docs/creating-a-provider.md is written to be enough on its own.
Deny by default, enforced at dispatch. Every capability is denied until you allow it, and policy only tightens as a request travels inward. gmail.search = allow with gmail.send = deny is a decision the runtime makes before anything is sent, not a rule the model is asked to respect.
The profile argument is required, not opt-in. There is no current profile and nothing to switch, so there is no default to be silently wrong about. Naming a connection from another profile is refused before dispatch.
The audit log is tamper-evident and yours. One append-only event per invocation, refusals included, with per-provider redaction that keeps identifiers and withholds content. Records are hash-chained per run, and lanes link audit verify walks every chain.
No database anywhere. State and the log are objects in a blob store: a directory on your machine locally, a bucket when deployed.
Local first. It needs Bun and no account anywhere. lanes link deploy stands up a Cloud Run revision on your own project when you need to reach it from the claude.ai web client, ChatGPT, or a phone.

Choose Lanes Link if

You want your OAuth tokens on infrastructure you control, not a vendor's.
You want the endpoint itself to be open source and runnable, not an SDK against a hosted runtime.
You want memory, skills, and a secret vault behind the same boundary as your accounts.
You want work and personal enforced per call rather than resolved by a default.
You want a tamper-evident audit log that you own and that outlives anyone's retention policy.

Choose Composio if

You need an integration Lanes Link does not have yet, which today is most of them.
You are embedding tool access into a product you ship to your own users.
You want sandboxes, triggers, or parallel execution as part of the platform.
You would rather someone else ran the OAuth applications and kept 1,300 connectors current.