I asked Cody, my collaborator in OpenAI’s Codex, whether Claude Code could consult it for a second opinion. Both are AI assistants I use to work directly with files on my computer. Once that route worked, I asked for the reverse: could Cody consult Claude?
That became two custom skills in my Obsidian notes vault: saved workflow instructions I can invoke when I want a review. Claude has /cody-advisor and Cody has $claude-advisor. Each starts a fresh session of the other tool with a short brief and paths to the relevant files. The advisor inspects the sources and reports back without changing the work. The session doing the work keeps the task and decides how to respond.
The advisors reviewed their own helpers
During setup, Cody reviewed the small bridge script that lets Claude call it. Stopping a consultation could leave the process carrying out the review still running. The script needed to stop that process too.
Claude then reviewed the script for the reverse route. It found a similar cleanup gap for a different stop signal, called a hangup.
It also caught the script overriding a saved setting for how much reasoning effort to request. The general setting was xhigh; Claude’s Opus model had an override of medium. The script requested xhigh anyway. The fix preserves the per-model preference. I haven’t measured what that changes in the advice.
Both reviewers had found problems in the code that made their own consultation possible. The fixes got local tests to check those problems didn’t return. Both routes also completed live consultations.
The test files were deliberately wrong
Two separate live tests used deliberate code errors. In the Claude-to-Cody test, a discount function returned 190 when a ten per cent discount on 200 should have returned 180. In the reverse test, a function rejected 10 when it was supposed to include that value.
Both reviewers found the planted errors in the source. The discount example stayed broken because only a review had been authorised. These were easy tests of whether each route could inspect the right file and return a finding. They don’t tell me how reliably either reviewer will catch difficult bugs. The script reviews were more interesting because those problems hadn’t been planted.
What the reviewer gets
Claude and Cody don’t automatically share the conversation. Each consultation starts fresh.
The working session prepares a short brief explaining what I’m trying to do and what I’ve authorised, with paths to the relevant files. It also needs to say what was actually checked. A test that passed, a test someone proposed, and a test nobody could run are different kinds of evidence.
Claude, when advising Cody, can read and search files, but has no command or editing tools. Cody, when advising Claude, can use commands in a read-only sandbox. Its instructions limit it to inspection and advice.
When tests matter, the session requesting the review supplies the results it actually obtained. The advisor has to distinguish its own checks from evidence supplied in that report.
I don’t want every consultation to carry my whole vault. The skills ask for relevant context and source paths, with instructions to exclude unrelated history and private agent memory.
The brief is still a point of failure. If Claude leaves out the awkward part of its approach, Cody may never know to question it. The reverse applies too. Access to the source helps, but someone has to identify the right source and ask a question worth answering.
Agreement still needs evidence
A fresh session gives the reviewer distance from the conversation that produced the work. It doesn’t guarantee independent reasoning. The brief carries the first session’s framing, and both tools may accept the same weak assumption.
Two reviewers agreeing wouldn’t settle that.
What I want back is a finding I can inspect. A source line that contradicts the summary gives me somewhere to look. A response that only says the plan looks sensible may offer very little to use.
This also puts a burden on the session asking for advice. It has to show how it responded to material findings. Silently accepting the review would hide the decision just as effectively as silently ignoring it.
I’ll have to decide when to ask
Both skills are manual. I haven’t added an automatic consultation after every task.
Each consultation takes another model call and time to assess the response. A tiny wording change can become slower without becoming better. Repeated reviews could also give me a respectable way to postpone finishing something.
The moments I’d use this are more specific. A fix keeps failing. A plan depends on an assumption I haven’t tested. A session says the work is complete, but the evidence doesn’t quite support the claim.
I haven’t used these skills enough to know how often they’ll earn that cost. The helper reviews have already led to fixes in code built for the consultations themselves. The next test is how often a second opinion catches something useful in ordinary work.
