Gigacode

Gigacode is Kolega Code’s answer to coding work that is too wide for a single agent loop. Instead of asking one model to serially inspect a whole repo, Kolega Code can launch many focused sub-agents, run them in phases, and synthesize their results.

It’s built for work where breadth matters:

Audit every package, module, or service area in parallel.
Run migration checks across many directories.
Assign independent implementation tasks after a plan is agreed.
Run several review agents against the same change and synthesize disagreements.
Use browser or investigation agents for external research while code agents inspect the repo.

For a quick question or a small, focused edit, the agent just does it directly — Gigacode is for genuine fan-out.

What Gigacode adds

When it’s enabled and a task calls for it, the agent writes a small workflow that can:

Run parallel phases — launch many sub-agents at once, wait for their results, then synthesize.
Pipeline work — send each package, directory, or topic through a sequence of stages independently.
Loop over broad surfaces — repeat a focused agent task across a list of files, modules, services, issues, or review targets.
Run judge panels — ask several agents to evaluate a change or plan from different angles, then reconcile disagreements.
Compose workflow shapes — use sweeps, matrices, funnels, pipelines, triage loops, and adversarial reviews when the task needs more structure than simple parallelism.
Preserve artifacts — save the workflow script, result files, transcripts, raw JSONL, and resume journal so the run is inspectable after the fact.

This is the main difference from ordinary one-off delegation: the agent can design a workflow, execute the wide parts concurrently, and return with the aggregate result.

Turning it on

Gigacode is off by default. Toggle it with the /gigacode slash command:

Command	Effect
`/gigacode`	Toggle gigacode on or off
`/gigacode on`	Enable workflow orchestration for the session
`/gigacode off`	Disable it

Headless runs use the --gigacode flag instead:

kolega-code ask "audit every API route for auth gaps" --gigacode

Once on, it stays on for that resumable session — if you quit and resume the same session, the setting is restored, whether you resume in the TUI or with kolega-code ask --session <id>. New sessions still start with Gigacode off. The agent decides when a task is worth orchestrating. It works in both Build and Plan modes — see Behavior and safety for how each differs.

What you’ll see

When the agent runs a workflow, the transcript shows phase headers and short progress lines as it works. Each sub-agent it launches appears in the sub-agent inspector — press Ctrl+G to watch every agent’s live trajectory, grouped by phase.

The run_workflow result is a compact artifact manifest. It includes paths like resultPath and transcriptPath; the completed workflow result is written to resultPath instead of returned inline. For normal workflow output, the agent should read those main files and avoid reading individual sub-agent transcripts. Raw and per-agent debug artifacts may exist under the run directory for explicit workflow debugging.

The agent should read those paths first — not re-run the workflow just to recover output text.

How it works

Under the hood, the agent authors a short Python script and runs it with a single run_workflow tool call. The script uses a handful of primitives:

Primitive	What it does
`agent(...)`	Dispatch one sub-agent and get its result back
`parallel([...])`	Run several sub-agents at once and wait for all of them
`pipeline(items, ...)`	Run each item through a series of stages independently
`phase(...)` / `log(...)`	Report progress to the UI

You don’t write these scripts — the agent does. A sketch of what it generates:

# Review three areas in parallel, then synthesize.
phase("Review")
findings = await parallel([
    (lambda area=area: agent(f"Review the {area} module for bugs"))
    for area in ["auth", "api", "cli"]
])
return findings

The stage names in a workflow are not fixed runtime types. The agent composes shapes from the task: a broad audit might map surfaces, sweep reviewers across them, verify findings adversarially, and synthesize; a planning task might funnel unknowns through research and option comparison; a debugging task might cluster failures, investigate root causes, test targeted fixes, and run a regression review. All of those shapes are built from the same primitives above.

Per-worker model overrides

Normally, each workflow worker inherits the model configured for its agent role through your CLI or host settings. Omitting model_override preserves those defaults and is the recommended behavior.

For a worker that needs a specific model, the main agent first calls the read-only list_subagent_models tool. The tool lists only providers configured for this session, their exact model IDs and effort options, vision support, and the effective defaults for each agent role. It can optionally filter by provider. Discovery is informational: the selection is validated again when the worker starts, and the tool never returns credentials, tokens, or private endpoint details. The result uses a compact Markdown table so exact routing values remain readable without the repeated keys of a large JSON payload.

The agent can then put one complete, atomic override on a workflow agent() call:

review = await agent(
    "Review the authentication design for subtle security flaws.",
    agent_type="investigation",
    model_override={
        "provider": "anthropic",
        "model": "claude-opus-5",
        "effort": "high",
    },
)

The contract is all-or-nothing:

When model_override is present, provider, model, and effort are all mandatory. Fields are not inherited individually.
For a model with effort controls, effort must be one of the exact strings reported by list_subagent_models.
Use "effort": None only for a model that has no effort control. None does not ask Kolega Code to choose that model’s default effort.
An unknown model, unsupported provider/model pair, unconfigured provider, or model-specific effort violation produces a failed worker result. A malformed model_override shape (including missing or extra fields) is a workflow script error; when it escapes the workflow’s own pipeline()/parallel() error handling, it fails the workflow. Neither case silently falls back to the inherited model or a provider default.
A Browser worker’s selected catalog entry must report supports_vision: true.

An override applies only to the direct worker launched by that agent() call. It does not reroute helper models or descendants. If delegation depth 2 is enabled, a child uses its own role default unless its own dispatch supplies a separate, complete override.

In Plan mode, Kolega Code first forces the requested workflow worker to the read-only Investigation agent, then validates and applies the override to that actual worker. Selecting another model never grants editing tools or bypasses Plan-mode safety.

Delegation depth

Workflow metadata has an optional max_agent_depth setting. It defaults to 1, which makes agents launched directly by workflow agent() calls leaf workers: they cannot dispatch child agents. The only other accepted value, and the hard maximum, is 2, which allows one worker-to-child hop; those nested children are always leaves.

Strongly prefer the default of 1 and represent fan-out visibly in the workflow with agent(), parallel(), and pipeline(). Depth 2 is an exceptional opt-in for a worker that genuinely needs to consult a specialist. Nested calls are less visible to workflow-level orchestration and can multiply token use.

Setting depth 2 only preserves dispatch tools that the direct worker’s agent type already supports. It never grants unsupported dispatch tools, and workers can never call run_workflow; the setting permits nested agent dispatch, not a nested workflow.

Depth-2 recursion supports built-in agent-dispatch tools only. Opaque host-provided ToolExtension dispatch callbacks are unavailable inside workflows until a workflow-aware accounting and depth protocol exists. This restriction does not change ordinary non-workflow extension or agent-delegation behavior.

Behavior and safety

How workflow sub-agents behave depends on the mode you’re in.

Plan mode — every workflow sub-agent is read-only (an Investigation agent), no matter what the workflow asks for. A model_override, when present, is validated for and applied to that forced Investigation worker; it changes routing, not permissions. Use Plan mode to fan out parallel research and synthesis while planning; it never edits your code.

Build mode — sub-agents have the full toolset and can edit files and run commands.

A few more guarantees:

By default, direct workflow workers are leaves. The optional delegation-depth policy is capped at one nested worker-to-child hop, and nested children cannot delegate further or run another workflow.
Workflow sub-agents don’t touch your task list — only the main agent manages it, so agents running in parallel can’t clobber it.
Concurrency caps active workflow execution chains rather than retained parent and child objects. Nested dispatch within one direct worker is serialized, so it cannot multiply that worker’s active chain.
There’s a hard ceiling on the lifetime number of agents a single workflow can spawn, as a runaway-loop backstop. Built-in nested workers count against that same workflow-wide total and its output-token budget.
Output-token budget admission uses completed spend. Once completed spend reaches the limit, later direct or nested launches are blocked; calls already in flight can still finish, producing bounded overshoot.
Run totals and failed-agent artifacts retain finalized output usage from direct and built-in nested workers, even when a later step fails.