If you are searching for source code for AI, you usually need one of three things: model code and weights, an open-source code agent that can plan and use tools, or an application stack that lets a model read files, run commands, and return a reviewable result. Those layers are related, but they are not the same product. The fastest way to make sense of the space is to separate the model, the agent loop, and the sandbox runtime that executes the work.
What “source code for AI” usually means
The phrase is broad enough that two people can use it and mean completely different things.
Sometimes it means model source: training code, inference code, tokenizer logic, and downloadable weights for an open model. Sometimes it means agent software: the tool that sits in a terminal or browser, reads a repository, plans a task, writes code, runs tests, and revises its own output. Sometimes it means product scaffolding around that agent: API calls, auth, sandbox lifecycle, file handling, logs, previews, and review gates.
That distinction matters because a team looking for an open model should not evaluate the same things as a team looking for an open-source coding agent.
Use this quick filter:
| If you need… | Look for… |
|---|---|
| A model you can run, fine-tune, or call through an API | Model repo, model card, license, context limits, tool-calling support |
| A coding tool that can act inside a project | Open-source code agent, CLI, desktop app, or agent platform |
| A production execution layer | Sandbox runtime, workspace isolation, package policy, secrets handling, logs, and previews |
Where to find source code for AI projects
For most developer workflows, the real answer is “in several repos, not one.”
1. Model repositories
This is where you find the model architecture, usage docs, checkpoints or checkpoint links, license terms, and benchmark notes. If your goal is local inference, fine-tuning, or studying how a model was packaged for coding tasks, start here.
For example, Qwen’s official Qwen3-Coder repository describes Qwen3-Coder-Next as an open-weight model built specifically for coding agents and local development, with long-context support and a function-call format aimed at agentic workflows.
2. Agent repositories
This is where you find the planner loop, tool wiring, terminal UX, model-provider adapters, and sometimes browser or MCP integrations.
Three useful examples:
- OpenHands positions itself as an open platform for cloud coding agents and a control center that can run agents locally, in Docker, on VMs, or through cloud backends.
- Goose is an open-source agent with desktop, CLI, and API surfaces that runs on your machine and is not limited to code tasks.
- Qwen Code is a terminal-oriented coding tool from Qwen that focuses on agentic coding workflows rather than generic chat.
If your main question is “what open-source code agent should I inspect first?”, start with the agent repos, not model weights.
3. Sandbox and runtime documentation
This is the layer many teams skip at first, then come back to when the agent starts doing real work.
Novita’s Sandbox documentation describes the runtime as an isolated, stateful environment for agents that need to run code, install dependencies, access files, use browsers, and preserve state across sessions. That is the execution boundary, not just a convenience wrapper. Once an agent can run commands, the runtime matters as much as the model.
What makes an open-source code agent different
An open-source code agent is not just an LLM with a prompt template. It becomes an agent when it can observe a workspace, decide on a next action, execute that action through tools, read the result, and keep iterating.
That loop usually needs four parts:
| Layer | Job |
|---|---|
| Planner | Break the task into steps and decide when the task is complete |
| Model | Reason over files, command output, and prior tool calls |
| Tool layer | Read files, write files, search, run commands, open previews |
| Sandbox | Isolate execution, keep workspace state, and contain side effects |
Without the sandbox, an “open-source code agent” often turns into “a model with dangerous shell access.”
That is also where the stack starts to look more like engineering infrastructure than a chat feature. Once the model can install packages, open ports, and rewrite files, you need to answer operational questions:
- What repository state does the agent start from?
- Which commands run automatically and which require approval?
- Can the agent fetch packages or browse arbitrary URLs?
- Where do logs, diffs, previews, and generated artifacts go?
- How do you pause, resume, or kill a session?
Those questions determine whether the project is a demo or a workflow your team can trust.
A practical coding-agent architecture
The cleanest way to think about source code for AI agents is as a chain:
- A user describes the task.
- The model turns the task into a plan.
- The agent calls tools to inspect the codebase.
- The runtime executes those tool calls in an isolated workspace.
- The model reads the results and decides what to do next.
- The system returns a diff, test output, and a summary a reviewer can verify.
That chain matters more than any single benchmark number. A model can be excellent at one-shot code generation and still fail as an agent if it struggles with tool calling, long context, or error recovery.
Before you launch into the planning loop, it is worth calling out one model direction that fits this stack well. If you want an open model that stays close to closed-source coding quality, Qwen3-Coder is one of the most practical options to evaluate first. Qwen’s official repo describes Qwen3-Coder-Next as an open-weight coding model for agents and local development, with results comparable to Claude Sonnet on agentic coding tasks. Novita’s current model catalog also exposes Qwen3 Coder Next, Qwen3 Coder 480B A35B Instruct, and Qwen3 Coder 30B A3B Instruct through the LLM API, which makes it easier to test the same family across different cost and quality tiers without rebuilding your integration.
How to build the stack with Novita
If you want a practical starting point instead of stitching together separate providers, the useful split is:
- Novita LLM API for reasoning, generation, and tool-calling models
- Novita Sandbox for isolated code execution and persistent workspace state
Novita’s LLM API is OpenAI-compatible, so you can point an existing OpenAI client at Novita by changing the base URL and model name.
Step 1: call a model through the OpenAI-compatible API
from openai import OpenAI
client = OpenAI(
base_url="https://api.novita.ai/openai",
api_key="YOUR_NOVITA_API_KEY",
)
response = client.chat.completions.create(
model="qwen/qwen3-coder-next",
messages=[
{"role": "system", "content": "You are a coding assistant."},
{"role": "user", "content": "Plan the steps to add rate limiting to a FastAPI login route."},
],
)
print(response.choices[0].message.content)That only gives you the model layer. It does not give the model a safe place to act.
Step 2: run code in a sandbox instead of on your laptop
Novita’s current Sandbox quickstart uses the Novita SDK object to create an isolated code interpreter session, run code, inspect files, and then shut the sandbox down when the task is complete.
from novita_sandbox import Novita
novita = Novita()
sandbox = novita.code_interpreter.create()
try:
execution = sandbox.run_code('print("hello from the sandbox")')
print(execution.logs)
files = sandbox.files.list("/tmp")
print(files)
finally:
sandbox.kill()That pattern is the simplest reliable starting point for an AI coding workflow:
- The model decides what should happen next.
- The sandbox performs the risky part in an isolated environment.
- The session can preserve state across the task instead of starting from scratch on each step.
Step 3: wire model decisions to tool execution
Once you add tool calling, the agent loop becomes straightforward:
| Tool | Purpose |
|---|---|
read_file | Load project files into model context |
write_file | Apply code changes |
search_files | Find symbols, routes, tests, or config entries |
run_command | Run tests, builds, linters, and setup commands |
list_files | Discover repository structure |
Novita also documents function calling and structured outputs for OpenAI-compatible model workflows. That matters because agent loops break easily when tool arguments are malformed or inconsistent. In practice, reliable tool calling is often more important than a flashy single-turn benchmark.
When open source is enough and when it is not
Open source is usually enough when:
- You want to inspect how the model or agent works.
- You want to self-host part of the stack.
- You need control over prompts, tools, and runtime behavior.
- You are comfortable owning the operational work.
Open source is usually not enough by itself when:
- You need stable multi-user execution with audit logs and review flows.
- You need isolation strong enough for untrusted code.
- You need model routing, pricing visibility, or several model tiers behind one API.
- You want the agent to keep state across longer tasks without building that runtime yourself.
This is the point where teams stop asking for “source code for AI” in the abstract and start asking which parts they actually want to own. Some teams want full control. Others want open models and open-source tools, but not the burden of running every runtime component themselves.
Conclusion
The best way to approach source code for AI is to stop treating it as one artifact. Model repos, open-source code agents, and sandbox runtimes solve different problems. If you mix them together, your evaluation gets muddy fast.
Start with the layer you actually need:
- Want local or self-hosted model control? Start with open model repos.
- Want an open-source code agent? Start with OpenHands, Goose, or Qwen Code.
- Want a working coding stack that can plan, act, and execute safely? Pair an OpenAI-compatible model API with an isolated sandbox runtime.
That is why the combination of an open coding model and a managed execution boundary is often the most practical path. You keep flexibility at the model layer without handing raw shell access to a model on your primary machine.
FAQ
Where can I find source code for AI?
Usually in three places: model repos, agent repos, and sandbox or runtime docs. If you want an open-source code agent, start with agent projects such as OpenHands, Goose, or Qwen Code instead of general model repos.
What is an open-source code agent?
It is an agent that can inspect files, plan a task, use tools, run commands, and revise its output inside a project. The important difference from a code assistant is action, not just generation.
Is model source code enough to build an AI coding agent?
No. A model alone does not give you repository access, tool wiring, execution control, logs, previews, or isolation. You still need an agent loop and a runtime where the model’s actions can execute safely.
What model should I test first for open coding workflows?
If you want an open model built specifically for coding agents, Qwen3-Coder is a strong place to start. The current Qwen3-Coder repo emphasizes agentic coding and long-context support, and Novita exposes several Qwen3-Coder variants through the same API.
Why do coding agents need a sandbox?
Because they run commands, install dependencies, and modify files. A sandbox gives the agent an isolated runtime, preserves task state, and limits the blast radius when the model does something wrong.
