The short version
CodeLynq uses Claude Code as one of its coding agents. The difference is not the model writing the code, but everything around it: where the work comes from, who agreed to it, what is checked before a pull request opens and who can see what it cost.
Teams that run Claude Code themselves usually start with a developer's terminal and later wire it into CI for reviews. CodeLynq is the step after that: a shared queue of approved work that the agent builds without anyone at the keyboard.
Where they differ
| Claude Code | CodeLynq | |
|---|---|---|
| Who starts the work | A developer at a terminal, or a mention in CI | The team's task queue, after a spec is approved |
| Before code is written | A prompt | A spec drafted against your codebase and approved |
| Checks before the pull request | Whatever you script around it | Your tests, self-review, security scan and architecture rules, each with a fix loop |
| Cost control | Usage per developer | A forecast per run, approval above a threshold, monthly limits |
| Record | The session on one machine | Task, spec version, run log, cost and audit trail |
| Where it runs | A laptop or a CI runner | Our platform or a runner on your own hardware |
Using both
Most teams keep Claude Code on developers' machines for the work they are actively doing, and let CodeLynq take the queue behind it. Because CodeLynq writes the same CLAUDE.md context and ends in an ordinary pull request, nothing about how your developers use Claude Code has to change. If you prefer OpenAI Codex or Grok for some work, the process around it stays the same.