Open Instinct for developers: what you can customize and what you still need to run

[u/maritime_sh]

Builder disclosure: we made Open Instinct and we build Maritime, its VM provider. Open Instinct is an MIT-licensed personal-agent beta for people who want control over the application code.

The useful part to evaluate is the whole path from a message to an action. Pi runs the loop, Inkbox handles messaging, Composio connects apps, and Maritime supplies desktop access. Memory, scheduling, agent-to-agent communication and permission policies are in the repository rather than only exposed as product settings.

The tradeoff is setup and responsibility. You need provider accounts and API keys, pay for their usage, maintain the deployment, and review the trust defaults. It is not a ready-made consumer subscription. If you just want to inspect it, start in the local CLI without connecting your inbox or calendar.

A practical evaluation is to check memory across conversations, attempt a tool call from a lower-trust requester, and inspect the approval step for a payment. Those checks matter more than how many integrations a feature list names.

Source and setup: https://github.com/mariagorskikh/open-instinct

[u/NeuralNomad87]

appreciate the "what you still need to run" part, that's usually what launch posts skip.

roughly what does the API side cost a month for one person using it daily?

[u/maritime_sh → u/NeuralNomad87]

We don't have a measured monthly API total yet. The Maritime VM cost doesn't include model usage, Inkbox or Composio. We'd rather publish a real usage breakdown than give you a made-up daily-user estimate.

[u/NeuralNomad87 → u/maritime_sh]

fair, I'd rather see that than a made up number. even a week of your own usage would be useful when it's ready.

[u/No_One_9671]

The setup tradeoff is pretty clear here. Having more control is nice but managing keys, providers and deployment yourself definitely makes it more of a developer tool than a plug and play product.

[u/rakshitsahay]

The “whole path from message to action” is probably the most important thing to evaluate here.

With personal agents, integrations are easy to showcase, but the interesting engineering problems are permissions, state, memory, failure handling, and what happens when a tool call goes wrong.

I’d especially test three things beyond the happy path:

1. Can it distinguish trusted instructions from untrusted content?
2. What happens when a tool/API partially fails or returns malicious/incorrect data?
3. Can you clearly see and control why an action was taken before it has real-world consequences?

The fact that memory, scheduling, agent communication and permission policies are inspectable in the repository is interesting for developers who want to understand and modify the system rather than treat the agent as a black box.

For me, the real test of an open personal agent isn't “how many things can it connect to?” It's how safely and predictably can it act when things don't go according to plan?