gitea/agents
8
0
Fork 0
Code Issues 2 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

readme #8

New Issue
Closed
opened 2026-07-02 17:09:04 +02:00 by ffaerber · 11 comments
ffaerber commented 2026-07-02 17:09:04 +02:00
Owner
Copy Link
Copy Source

the readme should contain a list of all agents and there model

the readme should contain a list of all agents and there model
ffaerber commented 2026-07-02 17:09:10 +02:00
Author
Owner
Copy Link
Copy Source

@pm here

@pm here
🚀 1
gitea-actions bot commented 2026-07-02 17:09:44 +02:00
Copy Link
Copy Source

🤖 @pm

Plan

The README already lists the agent names but not their models/capabilities. The authoritative data lives in the agent registry in .gitea/workflows/agent.yml (lines 54-61):

Agent Model Vision Mode
@pm anthropic/claude-sonnet-5 yes comment
@junior ollama/ornith:35b no pr
@senior ollama-cloud/glm-5.2:cloud no pr
@lead anthropic/claude-opus-4-8 yes pr
@qa anthropic/claude-sonnet-5 yes comment

Proposed change: add a small table like the one above (with the existing one-line descriptions from the registry) to README.md, right after the intro paragraph that currently just names the agents. I'd also add a one-line note that agent.yml's registry is the source of truth, so the table doesn't silently drift out of sync.

This is a single-file, low-risk documentation edit — a good fit for @junior.

@ffaerber ready to start building? reply yes to proceed.

🤖 **@pm** ## Plan The README already lists the agent names but not their models/capabilities. The authoritative data lives in the agent registry in `.gitea/workflows/agent.yml` (lines 54-61): | Agent | Model | Vision | Mode | |-------|-------|--------|------| | `@pm` | `anthropic/claude-sonnet-5` | yes | comment | | `@junior` | `ollama/ornith:35b` | no | pr | | `@senior` | `ollama-cloud/glm-5.2:cloud` | no | pr | | `@lead` | `anthropic/claude-opus-4-8` | yes | pr | | `@qa` | `anthropic/claude-sonnet-5` | yes | comment | Proposed change: add a small table like the one above (with the existing one-line descriptions from the registry) to `README.md`, right after the intro paragraph that currently just names the agents. I'd also add a one-line note that `agent.yml`'s registry is the source of truth, so the table doesn't silently drift out of sync. This is a single-file, low-risk documentation edit — a good fit for **@junior**. @ffaerber ready to start building? reply yes to proceed.
ffaerber commented 2026-07-02 17:30:18 +02:00
Author
Owner
Copy Link
Copy Source

@pm

i like to update the models for the agents to this

pm | ollama-cloud/gemma4:cloud
junior | ollama-cloud/kimi-k2.7-code:cloud
senior | ollama-cloud/glm-5.2:cloud
lead | anthropic/claude-opus-4-8
qa | ollama-cloud/glm-5.2:cloud

what do you think?

more info here https://ollama.com/search?c=cloud&c=vision&c=tools&c=thinking

@pm i like to update the models for the agents to this pm | ollama-cloud/gemma4:cloud junior | ollama-cloud/kimi-k2.7-code:cloud senior | ollama-cloud/glm-5.2:cloud lead | anthropic/claude-opus-4-8 qa | ollama-cloud/glm-5.2:cloud what do you think? more info here https://ollama.com/search?c=cloud&c=vision&c=tools&c=thinking
🚀 1
gitea-actions bot commented 2026-07-02 17:31:32 +02:00
Copy Link
Copy Source

🤖 @pm

Findings

I checked the Ollama Cloud model catalog (your link) and the registry logic in agent.yml before answering.

Model check — cloud/vision/tools/thinking tags:

Agent Proposed model Tags on Ollama Fits current vision requirement?
@pm gemma4:cloud vision, tools, thinking, cloud ✅ needs vision (reads issue images) — good fit
@junior kimi-k2.7-code:cloud vision, tools, thinking, cloud junior is vision:false today (text-only by design); this model can do vision but we'd just not use it — no problem either way
@senior glm-5.2:cloud tools, thinking, cloud (no vision) unchanged from today, already vision:false — fine
@lead anthropic/claude-opus-4-8 unchanged fine
@qa glm-5.2:cloud tools, thinking, cloud (no vision) ⚠️ conflict — see below

⚠️ The one real problem: @qa → glm-5.2:cloud.
@qa's entire job is driving Playwright, taking screenshots, and visually confirming bugs (vision:true today). glm-5.2 on Ollama Cloud is tools+thinking but has no vision tag — it can't read the screenshots QA takes. Switching QA to it would silently break its core capability (the workflow would still try to attach screenshots for a vision agent, but the model can't see them).

Two ways to resolve, your call:

  1. Keep QA on a vision-capable cloud model instead — e.g. kimi-k2.7-code:cloud or qwen3.5:cloud (both vision+tools+thinking+cloud), or
  2. Confirm you actually want QA to become text/log-only (no more visual screenshot review) — in which case we'd also update QA's description/vision:false and it stops doing visual confirmation.

One implementation detail for whoever builds this: agent.yml's opencode provider config hardcodes the allowed model IDs per provider (ollama-cloud.models currently only lists "glm-5.2:cloud"). Adding gemma4:cloud / kimi-k2.7-code:cloud requires adding entries there too, not just updating the agent→model routing table. I'll make sure this is called out in the build task either way.

@ffaerber which of the two options above do you want for @qa — a vision-capable cloud model, or drop vision for QA entirely?

🤖 **@pm** ## Findings I checked the Ollama Cloud model catalog (your link) and the registry logic in `agent.yml` before answering. **Model check — cloud/vision/tools/thinking tags:** | Agent | Proposed model | Tags on Ollama | Fits current `vision` requirement? | |---|---|---|---| | `@pm` | `gemma4:cloud` | vision, tools, thinking, cloud | ✅ needs vision (reads issue images) — good fit | | `@junior` | `kimi-k2.7-code:cloud` | vision, tools, thinking, cloud | junior is `vision:false` today (text-only by design); this model *can* do vision but we'd just not use it — no problem either way | | `@senior` | `glm-5.2:cloud` | tools, thinking, cloud (no vision) | unchanged from today, already `vision:false` — fine | | `@lead` | `anthropic/claude-opus-4-8` | unchanged | fine | | `@qa` | `glm-5.2:cloud` | tools, thinking, cloud (**no vision**) | ⚠️ **conflict** — see below | **⚠️ The one real problem: `@qa` → `glm-5.2:cloud`.** `@qa`'s entire job is driving Playwright, taking screenshots, and visually confirming bugs (`vision:true` today). `glm-5.2` on Ollama Cloud is tools+thinking but has **no vision tag** — it can't read the screenshots QA takes. Switching QA to it would silently break its core capability (the workflow would still try to attach screenshots for a vision agent, but the model can't see them). Two ways to resolve, your call: 1. Keep QA on a vision-capable cloud model instead — e.g. `kimi-k2.7-code:cloud` or `qwen3.5:cloud` (both vision+tools+thinking+cloud), or 2. Confirm you actually want QA to become text/log-only (no more visual screenshot review) — in which case we'd also update QA's description/`vision:false` and it stops doing visual confirmation. **One implementation detail for whoever builds this:** `agent.yml`'s opencode provider config hardcodes the allowed model IDs per provider (`ollama-cloud.models` currently only lists `"glm-5.2:cloud"`). Adding `gemma4:cloud` / `kimi-k2.7-code:cloud` requires adding entries there too, not just updating the agent→model routing table. I'll make sure this is called out in the build task either way. @ffaerber which of the two options above do you want for `@qa` — a vision-capable cloud model, or drop vision for QA entirely?
ffaerber commented 2026-07-02 17:35:04 +02:00
Author
Owner
Copy Link
Copy Source

@pm yes qa needs vision what do you think of minimax-m3?

@pm yes qa needs vision what do you think of minimax-m3?
🚀 1
gitea-actions bot commented 2026-07-02 17:35:33 +02:00
Copy Link
Copy Source

🤖 @pm

Confirmed model choices

minimax-m3:cloud — checked on Ollama's catalog: vision, tools, thinking, cloud. Solves the QA gap cleanly (same capability profile as your other picks, native multimodal, and per Ollama's blurb even beats Opus on BrowseComp for agentic/browsing tasks). Good fit for QA's screenshot-review job.

Final model table (as decided in-thread)

Agent Model Vision Notes
@pm ollama-cloud/gemma4:cloud yes unchanged role
@junior ollama-cloud/kimi-k2.7-code:cloud no (unchanged, still text-only by design) model has vision but we won't use it
@senior ollama-cloud/glm-5.2:cloud no unchanged
@lead anthropic/claude-opus-4-8 yes unchanged
@qa ollama-cloud/minimax-m3:cloud yes ✅ resolves earlier vision gap

Plan

  1. .gitea/workflows/agent.yml: update the agent→model routing table for @pm, @junior, @qa (senior/lead unchanged), and add the new model IDs (gemma4:cloud, kimi-k2.7-code:cloud, minimax-m3:cloud) to the ollama-cloud provider's allowed-models list — glm-5.2:cloud is already allowed.
  2. README.md: add the agent/model table (from my earlier comment, now with the updated models above) plus a one-line note that agent.yml is the source of truth.

Both are config/doc edits in the same two files, no logic changes — a good fit for @junior. Given this workflow is shared by every repo, I'll ask junior to double check the diff only touches the routing/model-list values and doesn't alter trigger/loop-guard logic.

@ffaerber ready to start building? reply yes to proceed.

🤖 **@pm** ## Confirmed model choices `minimax-m3:cloud` — checked on Ollama's catalog: **vision, tools, thinking, cloud**. Solves the QA gap cleanly (same capability profile as your other picks, native multimodal, and per Ollama's blurb even beats Opus on BrowseComp for agentic/browsing tasks). Good fit for QA's screenshot-review job. ## Final model table (as decided in-thread) | Agent | Model | Vision | Notes | |---|---|---|---| | `@pm` | `ollama-cloud/gemma4:cloud` | yes | unchanged role | | `@junior` | `ollama-cloud/kimi-k2.7-code:cloud` | no (unchanged, still text-only by design) | model has vision but we won't use it | | `@senior` | `ollama-cloud/glm-5.2:cloud` | no | unchanged | | `@lead` | `anthropic/claude-opus-4-8` | yes | unchanged | | `@qa` | `ollama-cloud/minimax-m3:cloud` | yes | ✅ resolves earlier vision gap | ## Plan 1. **`.gitea/workflows/agent.yml`**: update the agent→model routing table for `@pm`, `@junior`, `@qa` (senior/lead unchanged), and add the new model IDs (`gemma4:cloud`, `kimi-k2.7-code:cloud`, `minimax-m3:cloud`) to the `ollama-cloud` provider's allowed-models list — `glm-5.2:cloud` is already allowed. 2. **`README.md`**: add the agent/model table (from my earlier comment, now with the updated models above) plus a one-line note that `agent.yml` is the source of truth. Both are config/doc edits in the same two files, no logic changes — a good fit for **@junior**. Given this workflow is shared by every repo, I'll ask junior to double check the diff only touches the routing/model-list values and doesn't alter trigger/loop-guard logic. @ffaerber ready to start building? reply yes to proceed.
ffaerber commented 2026-07-02 17:37:13 +02:00
Author
Owner
Copy Link
Copy Source

@pm yes but use senior

@pm yes but use senior
🚀 1
gitea-actions bot commented 2026-07-02 17:37:30 +02:00
Copy Link
Copy Source

🤖 @pm

Approved — delegating to @senior

Maintainer confirmed: proceed, but assign to @senior instead of @junior (noted).

Scope for @senior:

  1. .gitea/workflows/agent.yml
    • Update the agent→model routing table:
      • @pm → ollama-cloud/gemma4:cloud
      • @junior → ollama-cloud/kimi-k2.7-code:cloud
      • @qa → ollama-cloud/minimax-m3:cloud
      • @senior and @lead unchanged
    • Add gemma4:cloud, kimi-k2.7-code:cloud, minimax-m3:cloud to the ollama-cloud provider's allowed-models list (glm-5.2:cloud already present).
    • Do not touch trigger gate or loop-guard logic — diff should be limited to model IDs/routing values.
  2. README.md
    • Add a table of agents/models (per the final table agreed in-thread) plus a one-line note that agent.yml is the source of truth for this mapping.

Since this workflow file is shared across all repos, please double-check the diff is scoped only to the routing table and model allow-list before opening the PR.

🤖 **@pm** ## Approved — delegating to @senior Maintainer confirmed: proceed, but assign to **@senior** instead of @junior (noted). **Scope for @senior:** 1. **`.gitea/workflows/agent.yml`** - Update the agent→model routing table: - `@pm` → `ollama-cloud/gemma4:cloud` - `@junior` → `ollama-cloud/kimi-k2.7-code:cloud` - `@qa` → `ollama-cloud/minimax-m3:cloud` - `@senior` and `@lead` unchanged - Add `gemma4:cloud`, `kimi-k2.7-code:cloud`, `minimax-m3:cloud` to the `ollama-cloud` provider's allowed-models list (`glm-5.2:cloud` already present). - Do **not** touch trigger gate or loop-guard logic — diff should be limited to model IDs/routing values. 2. **`README.md`** - Add a table of agents/models (per the final table agreed in-thread) plus a one-line note that `agent.yml` is the source of truth for this mapping. Since this workflow file is shared across all repos, please double-check the diff is scoped only to the routing table and model allow-list before opening the PR.
ffaerber commented 2026-07-02 17:37:30 +02:00
Author
Owner
Copy Link
Copy Source

@senior please proceed with issue #8 per the plan above (delegated by pm).

@senior please proceed with issue #8 per the plan above (delegated by pm).
🚀 1
gitea-actions bot commented 2026-07-02 17:37:34 +02:00
Copy Link
Copy Source

🔨 @senior is on it — building on branch ai/issue-8. I'll open a PR when it's ready.

🔨 **@senior** is on it — building on branch [`ai/issue-8`](https://git.ffaerber.duckdns.org/ffaerber/agents/src/branch/ai/issue-8). I'll open a PR when it's ready.
gitea-actions bot commented 2026-07-02 17:38:57 +02:00
Copy Link
Copy Source

🤖 @senior — ✅ 1 PR ready for review — @ffaerber please review & merge:

🤖 **@senior** — ✅ 1 PR ready for review — @ffaerber please review & merge: - https://git.ffaerber.duckdns.org/ffaerber/agents/pulls/9
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
autopilot
run agents without asking
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
ffaerber hermes intern junior lead ops (Ops Agent) pm qa (QA Agent) senior
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: gitea/agents#8