feat: Add OpenCode Backend Support with Performance Instrumentation & LinkedIn Optimizations

[rothnic]

feat: Add OpenCode Backend Support with Performance Instrumentation

Adds OpenCode CLI as an alternative backend to Claude Code for auto-apply orchestration.

Usage:

export APPLY_BACKEND=opencode
applypilot apply --url "https://linkedin.com/jobs/view/..."

Claude Code remains the default. OpenCode is opt-in via APPLY_BACKEND=opencode.

What's Included

• OpenCode backend - JSON streaming protocol, structured logging, unified status taxonomy
• Performance instrumentation - JSONL audit logs with per-action timestamps and LLM latency tracking
• LinkedIn optimizations - Fast-path Easy Apply instructions, overlay bypass for #interop-outlet
• Resume upload fix - Copy resume to worker directory for proper file access
• Pre-navigation - Chrome CDP HTTP endpoint for persistent tab creation
• analyze command - Post-run performance review via CLI

OpenCode Configuration Approach

Project Mode with XDG Isolation:

• Configuration: ~/.applypilot/.opencode/opencode.jsonc
• Custom agent: applypilot-apply defined in config
• XDG_CONFIG_HOME redirected to ~/.applypilot (isolates from global ~/.config/opencode/)
• Auth credentials preserved at ~/.opencode/auth.json (unaffected by redirect)

Custom Agent Definition:

{
  "agent": {
    "applypilot-apply": {
      "description": "Autonomous job application agent",
      "mode": "primary",
      "model": "github-copilot/gpt-5-mini",
      "prompt": "{file:../prompts/apply-agent.md}",
      "permission": {
        // Safety: deny file editing and bash
        "task": "deny",
        "edit": "deny",
        "write": "deny",
        "bash": "deny",
        // Read-only tools allowed
        "read": "allow",
        "grep": "allow",
        "glob": "allow",
        "lsp": "allow",
        // All Playwright browser tools enabled
        "playwright_browser_navigate": "allow",
        "playwright_browser_click": "allow",
        "playwright_browser_fill_form": "allow",
        "playwright_browser_snapshot": "allow",
        "playwright_browser_evaluate": "allow",
        "playwright_browser_file_upload": "allow",
        "playwright_browser_tabs": "allow",
        "playwright_browser_wait_for": "allow",
        "playwright_browser_screenshot": "allow",
        // All Gmail tools enabled
        "gmail_search_emails": "allow",
        "gmail_read_email": "allow",
        "gmail_send_email": "allow",
        "gmail_create_draft": "allow"
      }
    }
  }
}

Why This Approach:

• Prevents ApplyPilot's agent config from interfering with personal OpenCode workflows
• Allows per-project customization without polluting global config
• Keeps authentication separate from configuration
• Enables reproducible, isolated agent behavior

Instrumentation

Captures detailed timing data:

• LLM response time per turn
• Tool execution time (browser actions)
• Idle gaps between actions
• Token usage

Logs written to:

• worker-{id}.events.jsonl - Structured action history
• worker-{id}.perf.jsonl - Performance timing analysis

Observations

From instrumented runs:

• Chrome start → first response: 15-25s
• LLM response time: 5-20s per turn (variable)
• Tool execution: <200ms consistently
• LinkedIn #interop-outlet blocks ~30% of Playwright clicks
• Resume upload verification loops caused 30+ second delays

Files Changed (12 total)

Core Implementation (4 files)

File	Purpose
src/applypilot/apply/backends.py	OpenCodeBackend, JSON parsing, instrumentation
src/applypilot/apply/launcher.py	Pre-navigation, resume path handling
src/applypilot/apply/prompt.py	LinkedIn fast-path, existence-based workflows
src/applypilot/cli.py	analyze command

Supporting Changes (4 files)

File	Purpose
src/applypilot/config.py	Backend configuration
src/applypilot/wizard/init.py	Setup wizard updates
.env.example	Environment variable documentation
README.md	Documentation updates

Tests (4 files)

File	Purpose
tests/test_backend_selection.py	Backend selection tests
tests/test_parser_edge_cases.py	Parser edge case tests
tests/conftest.py	Test configuration
tests/__init__.py	Test package init

Future Optimization Opportunities

See section below for potential enhancements: custom tools, CLI optimizations, alternative browser automation (Camofox, agent-browser), MCP client direct connection, and platform-specific workflows.

---

Future Optimization Opportunities

This PR Is Intentionally Limited

This PR focuses solely on OpenCode integration and making it functional. The following optimizations are identified but intentionally left for future PRs to keep scope manageable:

1. Custom Tool Integration via OpenCode

OpenCode supports custom tools via MCP (Model Context Protocol). Potential optimizations:

• Domain-Specific Tools: Custom tools for LinkedIn/Indeed/Workday that understand platform structures
• Fast Selectors: Pre-computed selectors for common actions ("Find Easy Apply button", "Click Continue")
• State Machines: Tools that encode platform-specific workflows as state transitions
• Validation Tools: Fast verification tools that return structured data vs parsing HTML

2. CLI Tools with Stored Optimizations

Build CLI tools that leverage accumulated knowledge:

• Selector Database: Store working selectors per platform, update as UI changes
• Workflow Templates: Platform-specific step sequences (LinkedIn: Easy Apply → Contact → Resume → Questions → Review)
• Timing Profiles: Platform-specific wait times and retry patterns
• Fallback Chains: Ordered list of strategies when primary approach fails

3. Alternative Browser Automation

Current: Playwright via MCP. Alternatives to explore:

• Playwright CLI: Direct Playwright usage without MCP layer
• Agent-Browser: Purpose-built browser automation for agents
• Camofox: Firefox-based automation with enhanced stealth (avoid detection)
• Puppeteer: Chrome DevTools Protocol direct control

4. MCP Client Direct Connection

Instead of agent-managed MCP, use programmatic MCP client:

• Direct Server Connection: Connect to Playwright MCP server directly from backend code
• Batched Operations: Group multiple actions into single MCP calls
• Context Persistence: Maintain browser context across operations without agent re-initialization
• Reduced Overhead: Skip agent reasoning for known action sequences

5. Cached Analysis

• Page Pattern Cache: Store DOM structure patterns for known platforms
• Resume Parsing Cache: Cache parsed resume data across applications
• Job Analysis Cache: Avoid re-analyzing similar job descriptions

6. Parallel Execution

• Multi-Worker: Run multiple applications simultaneously
• Pipeline Architecture: Separate collection, analysis, and application phases

---

Migration

No migration required. Existing Claude Code users unaffected.

To try OpenCode:

export APPLY_BACKEND=opencode
applypilot apply --dry-run --url "https://linkedin.com/jobs/view/..."

---

Checklist

• OpenCode backend implementation
• JSONL audit logging with timestamps
• Performance instrumentation
• Pre-navigation fix (Chrome CDP)
• Resume upload path fix
• LinkedIn Easy Apply optimizations
• Modal overlay bypass
• analyze CLI command
• Merge conflicts resolved
• Python syntax validation
• PR description updated with abstractions and observations

---

Architecture Principle: Instrument first, optimize second. This PR establishes comprehensive instrumentation to measure before optimizing.

[i7opscom]

Does this have failover for applying with claude when spending cap reached? Have you tested other models for applying, do they all handle this equally well?

[rothnic]

At the moment, I'm implementing this focused on extending the coding agent abstraction with a switch to use opencode rather than claude code. It doesn't yet have a fallback, but it wouldn't be too difficult to support, though would do that as a follow up.

I currently have this working, but need to push some recent changes. I saw the other PR to add litellm support, so I pulled out the openai compatible api support from this PR, and am focused only on the opencode support/coding agent abstraction.

Overall issues i'm seeing right now, is just that the prompt.py isn't really adequate, though at the moment I am using a very cheap model (gpt-5-mini) for testing that isn't as smart as the default one used. For example, the job I'm using for testing the application dry run wanted me to sign in with linkedin, but didn't seem to try to the option to click the continue with google button, it seemed to only want to use username and password. I signed into the browser with google so it would have easy access to social sign in, but it was explicitly told to only use username and password. I think the current challenge is we really need multiple well defined tests that test out the agent applying for positions across multiple sites that have different characteristics

I do think that the current implementation of the agentic application is somewhat slow and could be significantly faster with better tooling, skills focused on particular families of sites, alternative browsers that would be less likely to have to solve captchas (camofox) or more efficient cli options (agent-browser), or code-mode, combined with config-driven custom tools. Ideally, when the agent is browsing it would more proactive information about the site and would avoid so much slow back and forth playwright tools. However, at the moment, my main focused for this PR is just adding the opencode support and any prompt optimizations to make sure it works for me and I'm pretty much there now.