I’ve been playing with “AI”, or LLMS, for a long time, but recently I started using 2 of them as a semi-distributed system. It works far better than I expected!
Most people try to pick one AI and make it do everything. That approach hits limits fast. I use a system that combines two LLMs with local storage and helps with session limits, context loss, and cost issues that frustrate most people. I got very tired of hitting session limits, re-explaining context to ChatGPT and Claude, especially Claude as its quite expensive for the limits that are imposed…
This article explains the technical setup and why it works better than trying to optimize for a single model.
The Problem With Single-Model Usage
Using one LLM for everything creates friction:
Token limits – You hit caps when working with large documents or extended sessions.
Session windows – Claude has a 5-hour session limit. When it expires, you lose all context.
Context loss – Every new session starts from zero. You re-explain the same project background repeatedly.
Cost management – Heavy usage on paid tiers adds up. Free tiers have restrictive limits.
The typical response is to switch models or go local. That misses the actual issue. The problem is trying to make one component handle exploration, execution, memory, and tool integration. Each requires different characteristics.
System Architecture
I run a distributed system with four components:
- ChatGPT – Continuous exploration and planning
- Claude – Batch execution and synthesis
- Obsidian – Persistent knowledge storage
- MCP – Protocol layer connecting Claude to Obsidian
Each component handles what it does best. The system has state even though individual LLMs are stateless.
Component 1: ChatGPT as Coordinator
ChatGPT runs continuously throughout the day. I use it for:
- Exploring unclear requirements
- Structuring problems before solving them
- Working through competing ideas
- Refining vague tasks into specific actions
ChatGPT has high session limits, with a rolling model, so there’s no pressure to “make the most” of each interaction. It’s a thinking space.
By the time I move to execution, the task is already well-defined. ChatGPT doesn’t produce final output. It clarifies what the final output should be.
Component 2: Claude as Execution Engine
Claude gets used deliberately and only when I already know what I’m doing.
Used for:
- Large document synthesis
- Structured content creation (training materials, documentation)
- Multi-file code generation
- Technical analysis requiring deep context
I treat it like a batch job. Enter with a clear goal, provide all necessary context upfront, execute to completion. The 5-hour session limit doesn’t really matter because I’m not using it for rolling exploration.
Component 3: Obsidian as Persistent Storage
My Obsidian vault contains:
- Daily work logs
- Project notes with decisions and context
- Technical documentation
- Conversation summaries
- Long-running ideas and research
This is human-authored memory. Chronological, searchable, local. It persists regardless of API changes or service availability.
When working with Claude, I reference vault notes. When finishing work in ChatGPT, valuable outputs get passed to Claude and then the completed projects get documented in the vault, sometimes by Claude itself.
Past work becomes accessible to future work, this has an overall huge effect as the context survives beyond individual sessions.
Component 4: MCP as Protocol Layer
MCP (Model Context Protocol) connects Claude to the Obsidian vault.
Capabilities:
- Query notes by content or date
- Pull historical context into current sessions
- Write outputs directly to the vault
- Reference multiple documents simultaneously
Without MCP, I’d manually copy-paste between Claude and Obsidian. Project context would need re-explanation every session. With MCP, Claude accesses accumulated knowledge directly.
This turns the LLM from an isolated tool into a participant in the knowledge system.
How This Maps to Distributed System Patterns
ChatGPT = Lightweight coordinator. Always available. Handles routing and planning.
Claude = Heavy worker node. Invoked on-demand. Handles compute-intensive synthesis.
Obsidian = Persistent data layer. Durable storage. Queryable state.
MCP = Interface protocol. Standardized communication between components.
Individual components are stateless. ChatGPT doesn’t remember previous sessions. Claude forgets when sessions end, although it does do a better job than ChatGPT and searching through its own history, but the system maintains a much “fuller” state in Obsidian.
Nothing needs to do everything, each part of the system handles its designated function.
Practical Outcomes
This setup changes daily workflow:
Reduced repetition – Context persists. I don’t re-explain project background.
Faster execution – Less time ramping up. More time on actual work.
Consistent outputs – New work references past decisions and patterns.
Lower cognitive load – No mental tracking of “what I told which AI.”
Compounding value – The system gets more useful as the knowledge base grows.
Cost and Resource Management
ChatGPT – Free tier works fine for exploration. Paid tier is $20/month if needed.
Claude – Used sparingly for execution only. Paid tier manages costs better than using it for everything.
Obsidian – Free. Local storage.
MCP – Open source. No cost.
Total cost: $20-40/month depending on usage. Compare this to trying to run everything through one paid tier with heavy usage.
Technical Setup
Prerequisites:
- Obsidian installed locally
- ChatGPT account (free or paid)
- Claude account (free or paid)
- MCP server configured
Workflow:
- Use ChatGPT to explore and define tasks
- Document outcomes in Obsidian
- Invoke Claude with vault context via MCP
- Write outputs back to vault
- Reference vault knowledge in future sessions
The setup takes a few hours initially. Daily workflow is straightforward once established.
When This Approach Works
Best suited for:
- Knowledge workers managing multiple projects
- Technical writing and documentation
- Training content creation
- Consulting work requiring client context
- Software development with legacy codebases
- Research synthesis across multiple sources
Less useful for:
- One-off queries
- Simple factual questions
- Tasks with no need for historical context
Summary
Trying to optimize AI usage by picking “the best model” misses the point. Different tasks need different characteristics. Building a system around specialized components handles more use cases than trying to make one LLM do everything.
The setup described here uses ChatGPT for exploration, Claude for execution, Obsidian for memory, and MCP for integration. Each component handles what it does well. The system maintains state even though individual LLMs don’t.
This eliminates session limits, preserves context across time, manages costs effectively, and reduces cognitive overhead.
The value is in the system architecture, not in any single model.