The problem
Earlier this week I needed deep research to inform an options analysis I was co-building with Claude Code. The workflow went like this: open four different LLMs in Chrome tabs, run the same query in each, wait for the results, download the reports, import them back into my project, then ask Claude Code to work with them.
It worked. But it was slow, manual, and the output wasn't structured in a way Claude Code could pick up and run with. Every time I needed research to feed a build task, I was leaving the tool I was building in, doing a bunch of tab-switching and copy-pasting, then spending time reformatting so the context was actually usable.
The deeper issue: every model has blind spots. Different training data, different retrieval sources, different framing. Ask Claude and Perplexity the same question and you'll get different sources, different emphasis, and sometimes flat-out contradictory claims. Relying on a single model means you never see what it left out.
What I built
Parallel Research is a Claude Code skill that runs Claude, OpenAI, Gemini, and Perplexity on the same research topic at the same time. One command, four models, structured output that drops straight into your project.
/research "How do blockchain gaming economies handle inflation?"
Each model's response lands as its own markdown file with consistent formatting: summary, key findings, sources, unique insights, and limitations. There's also an optional meta-analysis that cross-references all four outputs and scores each finding by how many models independently arrived at the same conclusion.
Under the hood, it's a Python asyncio orchestrator that hits all four APIs concurrently. If one provider fails or you don't have a key for it, the others still complete. The output follows a three-phase pipeline: parallel fetch, structured processing, then optional cross-model synthesis.
Why it matters
This supports internal ops efficiency. It collapses a multi-tool, manual research process into a single command inside the tool you're already building in.
The research lives where the work happens. No tab-switching, no downloading reports, no copy-pasting fragments out of chat windows. You type /research, the structured output lands in .research/, and Claude Code can reference it directly in whatever you're writing next.
The second piece of value is coverage. When three out of four models independently reach the same conclusion, that's a high-confidence signal. When only one model surfaces a finding, you know to dig deeper before trusting it. A single model gives you a confident answer with no indication of what it missed. Running them in parallel turns that into a map of where the answers converge and where they diverge.
For options analyses, technical spikes, competitive questions, policy docs, anything where research feeds a real decision, knowing where the models agree and disagree is more valuable than any one model's response on its own.
How the output is structured
.research/
├── raw/ # Raw API responses
├── structured/ # Processed output per model
│ ├── claude-topic.md
│ ├── openai-topic.md
│ ├── gemini-topic.md
│ └── perplexity-topic.md
├── meta-analysis.md # Cross-model synthesis
└── research.yaml # Manifest tracking status and timings
Every file follows the same template with YAML frontmatter. Three depth settings: quick (single call per model, under a minute, a few cents), standard (three-call refinement chain, under three minutes), and deep (native deep research where the provider supports it).
Who benefits
Anyone using Claude Code who needs research to inform what they're building. The output is structured so Claude Code treats it as project context, not just text you read once. That means the research feeds directly into the next task, whether that's drafting an options paper, writing a technical recommendation, or building something new.
Where to find it
The project is open source on GitHub: github.com/AdenCJM/parallel-research