A local-first coding agent framework β Codex-style repository automation, without handing your codebase to a black box.
Your repo. Your machine. Your rules.
π€ Why This Exists Β· β¨ What Makes It Different Β· π Architecture Β· π¦ Install Β· πΊ Roadmap Β· π€ Contributing
Every major AI coding agent forces the same trade-off: ship your repository to a vendor's cloud, or give up autonomous workflows entirely.
That trade-off is unnecessary. And it's expensive:
- Your code β env vars, internal tooling, proprietary logic β leaves your machine
- Execution is opaque. You can't audit what the agent actually did to your codebase
- You're locked to one provider's roadmap, pricing, and uptime
- Most agent codebases calcify into unmaintainable spaghetti before the approach is even proven
Qwen3CoderNext exists because "autonomous" and "auditable" shouldn't be opposites.
It's a coding agent foundation built on infrastructure you control, where every read, write, and command is logged, checksummed, and replayable β before any autonomous behavior is layered on top.
This project is under active development, built incrementally with a completed-layer-first discipline.
Completed:
- Foundation Layer
- Local Tooling Layer
- Planning Layer
- Failure Recovery Layer β Steps 1-9 complete
- Repository Intelligence β Part 9 Steps 1-9 complete
- Code Knowledge Graph β Part 10 Steps 1-7 complete
Current focus:
- Agent Core
- Execution Layer
- Repository Intelligence and Graph integration into runtime workflows
- Evaluation Layer integration
| Typical Cloud Coding Agents | Qwen3CoderNext | |
|---|---|---|
| Where it runs | Vendor's cloud | Your machine / your infra |
| Execution visibility | Opaque | Append-only, sequence-numbered audit log |
| Repo boundaries | Implicit, trust-based | Explicitly enforced |
| Generated files | Ephemeral | Checksum-verified, versioned, provenance-tracked |
| Provider lock-in | High | Model-gateway abstraction β swap providers freely |
| Build philosophy | Ship autonomy, bolt on reliability later | Deterministic infrastructure first, intelligence layered on top |
- Local-first execution β your repository and credentials never have to leave your machine
- Enforced workspace boundaries β the agent physically can't wander outside the repo it's working in
- Safe, reversible file operations β reads, patches, and writes go through a controlled pipeline, not raw filesystem access
- Full audit trail β every action is append-only logged and replayable, so you always know what happened and why
- Provenance-tracked artifacts β every generated file is checksum-verified with a supersede history, never silently overwritten
- Provider-independent model gateway β change models without rearchitecting your workflow
- Built to be understood β modular, contract-driven components instead of one sprawling agent loop
flowchart TD
U[User / CLI] --> O[Orchestrator]
O --> PL[Planning Layer]
O --> MG[Model Gateway]
O --> TF[Tool Framework]
PL --> RI[Repository Intelligence]
RI --> KG[Code Knowledge Graph]
TF --> FS[Filesystem Service]
TF --> CMD[Command Execution]
TF --> AR[Artifact Registry]
FS --> AL[Audit Log]
CMD --> AL
AR --> AL
O --> FR[Failure Recovery]
FR --> CP[Checkpoint / Rollback]
FR --> LED[Recovery Ledger / Metrics]
RI -.->|repository facts| PL
KG -.->|code structure / traversal| PL
O -.->|integration in progress| EX[Execution]
O -.->|not yet fully wired| MEM[Memory]
Solid lines = implemented, validated, and available as project components. Dashed lines = implemented boundaries that are not yet fully wired into the runtime agent loop.
Component breakdown:
| Component | Role | Status |
|---|---|---|
| Orchestrator | Coordinates planning, tools, recovery, and runtime execution boundaries | β |
| Planning Layer | Request normalization, task decomposition, dependency resolution, artifact generation | β |
| Model Gateway | Routes requests across supported model providers | β |
| Tool Framework | Contract, registry, manager, and tool adapter infrastructure | β |
| Filesystem Service | Workspace boundaries, safe reads/writes, patches, and diffs | β |
| Artifact Registry | Checksum, provenance, and supersede tracking for generated files | β |
| Audit Log | Append-only, sequence-numbered action history | β |
| Failure Recovery | Failure classification, strategy selection, bounded execution, checkpoint/rollback, ledger/metrics, scenario tests | β |
| Repository Intelligence | Scanning, classification, dependency hints, summaries, persistence, incremental refresh, queries, fixture integration | β |
| Code Knowledge Graph | Graph contracts, parser adapters, relation normalization, storage, traversal, invalidation, export | β |
| Memory | Runtime-owned persistent context and working-memory infrastructure | π§ Integration pending |
| Agent Core | End-to-end task execution and runtime wiring across the completed layers | π§ Active |
- Core contracts (artifact, model, runtime, state, task)
- Configuration system (settings, loader, defaults)
- Structured logging infrastructure
- State management (manager, store)
- Model gateway and adapter layer
- Runtime context and orchestrator shell
- Artifact manager and store
- Prompt infrastructure (contracts, loader, registry)
- Evaluation foundation
- Workspace resolution and boundary enforcement
- Filesystem service abstraction
- Safe file reads, writes, and patch application
- Diff generation
- Command execution
- Artifact registry
- Audit logging
- Tool adapter integration
- Request normalization
- Task decomposition
- Dependency resolution
- Validation
- Planner state management
- Artifact generation
- Deterministic serialization
- Runtime integration
- Part 9 Steps 1-9 complete
- Immutable repository contracts and snapshot schema
- Deterministic repository scanning and ignore handling
- File classification and language detection
- Shallow dependency hint extraction
- File and folder summary generation
- Manifest persistence
- Incremental refresh and change journaling
- Snapshot-backed query service
- Fixture-driven end-to-end integration tests
- Immutable graph schemas and canonical IDs
- Parser adapter boundary with deterministic Python AST parsing
- Relation normalization and symbol resolution
- Persistent graph snapshot storage and publication
- Bounded deterministic graph traversal
- Invalidation and incremental reconciliation
- JSON, CSV, and text graph export
- Wiring the completed layers into the orchestrator
- Building real end-to-end task execution
- Runtime integration of repository intelligence and graph services
- First complete CLI workflow
Agent Core is not yet complete. This is the full intended workflow once it lands.
You: "Refactor the auth module to use the new session interface."
β
βΌ
Planning Layer
(decomposition Β· dependency resolution Β· artifact generation)
β
βΌ
Research Layer
(schemas Β· state Β· request normalization Β· source policy)
β
βΌ
Execution
(controlled, audited, boundary-enforced)
β
βΌ
Local Tooling
(filesystem reads Β· patch application Β· command execution)
β
βΌ
Audit Log
(every action checksummed and replayable)
β
βΌ
Artifacts
(provenance-tracked Β· versioned Β· never silently overwritten)
β
βΌ
Human Approval Gate
β
βΌ
Main Branch
git clone https://github.com/neural-agi/Qwen3-coder-next.git
cd Qwen3-coder-next
uv syncThe fastest way to verify the foundation is solid while Agent Core is being built:
uv run python -m unittest discover -s tests -v329 tests. Zero failures.
| Test Tier | Coverage |
|---|---|
tests/smoke/ |
Deterministic subsystem and contract smoke tests β contracts, configuration, logging, state, tooling, planning, recovery, repository intelligence, graph foundations, runtime, and subsystem boundaries |
tests/unit/ |
Deep subsystem-level tests β detailed coverage for local tooling and core infrastructure |
tests/integration/ |
End-to-end integration coverage β local tooling and repository-intelligence integration flows |
Qwen-3-Coder-Next/
βββ src/qwen3_coder_next/
β βββ __main__.py # CLI entry point
β βββ adapters/ # model gateway, base adapter, exceptions
β βββ artifacts/ # artifact manager and store
β βββ bootstrap/ # app bootstrap, runtime initialization
β βββ config/ # settings, loader, defaults
β βββ contracts/ # core type contracts β artifact, model, runtime, state, task
β βββ evaluation/ # evaluation contracts, evaluator, simple_evaluator
β βββ execution/ # execution contracts and result types
β βββ extractors/ # graph relation normalization and symbol resolution
β βββ graph/ # graph schemas, storage, traversal, invalidation, export
β βββ local_tooling/ # filesystem, reads, mutations, diff, commands,
β β # artifact registry, audit, resolution, adapter, contracts
β βββ logging/ # formatter, logger, setup
β βββ memory/ # schemas, state, contracts, manager, store
β βββ parsers/ # parser contracts and language adapters
β βββ planning/ # contracts, planner, decomposition, validation
β βββ repo_intelligence/ # repository contracts, scanner, classifier, dependencies,
β β # summaries, manifests, refresh, query services
β βββ research/ # research schemas, state, source policy, pipeline
β βββ prompts/ # contracts, loader, registry
β βββ runtime/ # orchestrator, runtime context
β βββ state/ # state manager and store
β βββ tools/ # contracts, registry, manager, echo_tool
β βββ utils/
β
βββ tests/
β βββ smoke/ # Deterministic subsystem and contract smoke tests
β βββ unit/ # Deep subsystem-level tests
β βββ integration/ # End-to-end subsystem integration tests
β
βββ documents/ # internal architecture docs
β βββ architecture.md
β βββ vision.md
β βββ roadmap.md
β βββ coding_standards.md
β βββ progress.md
β βββ session_handoff.md
β
βββ Roadmap and Module wise expansion/ # 15 PDFs β full Tier 3 roadmap
β βββ Part 1: Foundation
β βββ Part 2: Filesystem + Local Tooling
β βββ ... (Parts 3β14)
β βββ Part 15: Near-Codex Integrated System
β
βββ logs/ # application.log β the system already runs
βββ pyproject.toml, uv.lock
βββ README.md
documents/ β Internal architecture specifications, coding standards, progress tracking, and session context. Start here before touching code.
Roadmap and Module wise expansion/ β 15 PDFs covering the complete Tier 3 roadmap from Foundation through Near-Codex Integrated System. If you want to understand the layering decisions, start with the master roadmap PDF.
| Layer | Focus | Status |
|---|---|---|
| Foundation | Contracts, config, logging, state, model gateway, orchestrator, artifacts | β Complete |
| Local Tooling | Filesystem, reads/writes, commands, audit, artifact registry | β Complete |
| Planning Layer | Request normalization, task decomposition, dependency resolution, runtime integration | β Complete |
| Failure Recovery | Failure classification, recovery strategy, execution, rollback, ledger/metrics, chaos validation | β Complete |
| Repository Intelligence | Contracts, scanning, classification, dependency hints, summaries, persistence, refresh, queries, integration tests | β Complete |
| Code Knowledge Graph | Graph contracts, parsing, normalization, storage, traversal, invalidation, export | β Steps 1-7 |
| Agent Core | Runtime integration, real task execution, CLI | π§ Active |
| Execution Layer | Controlled execution pipeline and autonomous task execution | π§ In Progress |
| Memory Layer | Persistent context, session memory, cross-task recall | π§ Integration pending |
| Autonomous Workflows | End-to-end task execution with human approval gates | π Planned |
| Multi-Agent Architecture | Coordination, specialization, parallel execution | π Planned |
The full 15-part roadmap is documented in Roadmap and Module wise expansion/.
Privacy-conscious developers and teams who can't or won't send proprietary code, internal tooling, or environment secrets to a third-party cloud agent.
Teams under compliance constraints β legal, financial, healthcare β where code leaving the machine isn't an option, but autonomous development workflows still are.
OSS maintainers who want reproducible, auditable automation in CI without a vendor dependency.
Builders and researchers who want a clean, contract-driven foundation to build agent behavior on top of β rather than forking an opinionated monolith and fighting its design assumptions.
Qwen3CoderNext is early β contributing now means shaping the foundation, not just adding to it.
Read CONTRIBUTING.md for full setup instructions, coding guidelines, pull request expectations, and the project philosophy before opening anything.
The short version:
- Open an issue before large changes β architecture decisions need to stay consistent with existing contracts
- Tests are not optional β every subsystem has smoke, unit, and integration coverage; PRs that reduce coverage don't merge
- Read the relevant
documents/spec and roadmap PDF for the module you're touching β it saves significant back-and-forth
Where to contribute right now:
| Area | What's Needed |
|---|---|
| π§ Agent Core | Orchestrator integration, end-to-end task execution, memory wiring, CLI entrypoint |
| π§ Repository / Graph Integration | Connect repository intelligence and graph services to runtime workflows |
| π§ͺ Test Coverage | Additional integration, regression, and end-to-end tests across completed layers |
| π Documentation | Architecture docs, setup guides, examples, and subsystem documentation |
Most agent projects ship a capable-looking agent first and try to add reliability later. The result is an autonomous system that's hard to trust, hard to debug, and hard to extend β because the foundation wasn't built for those properties.
Qwen3CoderNext takes the opposite path: deterministic, testable infrastructure first. Every subsystem is validated before the next layer is added. Every layer is completed, validated, and frozen before higher-level systems are allowed to depend on it.
The long-term target is a fully autonomous, multi-agent development platform β repository understanding, persistent memory, multi-model collaboration, human approval gates β that never asks you to give up visibility into what it's doing or where your code lives.
329 automated tests. Deterministic infrastructure. Failure Recovery Steps 1-9 complete; Repository Intelligence Steps 1-9 and Part 10 Steps 1-7 graph foundations are implemented.
Qwen3CoderNext is licensed under the MIT License.
You're free to use, modify, distribute, and build upon this project in accordance with the terms of the license.
See the LICENSE file for the full license text.
Built by @neural-agi