# Intel Arc B580 AI Compatibility Tracker (`codeclouds/arcor`) Actor

Evidence-first Intel Arc B580 checks for Ollama, llama.cpp, ComfyUI and Intel software stacks, with live release metadata, model lookups and explicit GitHub issue tracking.

- **URL**: https://apify.com/codeclouds/arcor.md
- **Developed by:** [Dennis](https://apify.com/codeclouds) (community)
- **Categories:** Developer tools, Other
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $2.00 / 1,000 compatibility records

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

An Actor is a serverless cloud program that runs on the Apify platform. It has two run modes.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.

Apify vocabulary and the platform model are defined once, in the agent quickstart at https://apify.com/agents.md.

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.

Do not guess an integration path. Every one of them is in the agent quickstart at https://apify.com/agents.md: the Apify MCP server, Agent Skills with the Apify CLI, the JavaScript and Python clients, the REST API, and the account-free path for an agent with no human to sign in. It also carries the rule on stating cost before the first paid run.

For examples already wired to this Actor's own input schema, see the [API](#api) section below.

Each client library has reference documentation the quickstart does not restate: [JavaScript/TypeScript](https://docs.apify.com/api/client/js/docs.md) (`npm install apify-client`) and [Python](https://docs.apify.com/api/client/python/docs.md) (`pip install apify-client`).

# README

## Intel Arc AI Stack Compatibility Tracker

Evidence-first compatibility checks for Intel Arc B580 AI stacks. `arcor` helps developers, platform engineers, and AI agents decide what is known, what is supplied by the caller, and what still needs verification. It combines explicit stack configurations, live Intel/GitHub release metadata, model-catalog lookups, and user-selected GitHub issues into a consistent, machine-readable dataset.

The actor is deliberately cautious. It never invents a fallback release, never turns missing evidence into a positive compatibility verdict, and never presents a stale cached response as a fresh source check. A result can be `live`, `cached`, `input`, or `error`; the source URL, source timestamp, run timestamp, confidence, and evidence are included whenever they are available.

### When should an AI agent use this?

Use this actor when a question involves one of the following:

- “Can this Ollama, llama.cpp, ComfyUI, or Intel software configuration run on an Arc B580?”
- “What is the latest relevant Intel release metadata, and does the release mention Arc hardware?”
- “Is this GitHub issue still open, and has its status changed since the previous run?”
- “Does this model identifier exist in the Hugging Face catalog, and what compatibility evidence is actually available?”
- “Give me a structured, source-aware result for an automated deployment or monitoring pipeline.”

The actor is not an official Intel product and does not replace a hardware test. It is a decision-support and evidence-collection tool. A configuration marked `unknown` means exactly that: the available evidence is insufficient for a reliable yes/no verdict.

### Keywords

Intel Arc, Arc B580, B580, AI compatibility, Ollama, llama.cpp, ComfyUI, IPEX, Intel oneAPI, XPU, GGUF, model compatibility, GitHub issue monitor, release monitor, evidence, AI agent, Docker, Ubuntu, local LLM, inference, structured output.

### Quick start

The default demo input is deliberately local and does not call external APIs:

```json
{
  "monitorMode": "dataset_only",
  "seedConfigs": [
    {
      "gpu": "Arc B580",
      "os": "Ubuntu 24.04 LTS",
      "driver": "Linux 6.8+",
      "aiEngine": "ollama",
      "engineVersion": "0.5.7",
      "modelFormat": "GGUF INT8",
      "works": "unknown"
    }
  ]
}
```

The result contains a stable configuration ID, a source status, the normalized stack fields, and an `assessment` object. Change `works` to `confirmed`, `partial`, or `failed` only when that status is supported by your own test evidence. Add `source` and `verifiedAt` to make the evidence auditable.

For a live release check:

```json
{
  "monitorMode": "live",
  "modelQuery": "qwen2.5"
}
```

For a tracked issue, use a real GitHub issue reference:

```json
{
  "monitorMode": "bugs_only",
  "trackBugIds": ["owner/repository#123"],
  "includeUnchangedBugs": false
}
```

The actor accepts `owner/repository#number` and full `github.com/.../issues/...` URLs. Pull requests and unsupported Intel-specific identifiers are returned as explicit source errors rather than being mislabeled as bugs.

### Monitor modes

- **`live`** fetches current `intel/llm-scaler` release metadata and the latest tag from Intel’s archived `intel-extension-for-pytorch` repository. It performs an optional model lookup when `modelQuery` is set.
- **`dataset_only`** assesses the configurations supplied in `seedConfigs` and optionally looks up a model. It does not inject demo configurations.
- **`bugs_only`** fetches only the explicitly supplied GitHub issues and compares their state with the previous successful run.
- **`full`** combines live releases, supplied configurations, tracked issues, and an optional model lookup. Each source is deduplicated by its canonical ID.

`includeUnchangedBugs` is `true` by default so a current snapshot is returned. Set it to `false` for change-oriented monitoring; a new or updated issue remains visible, and a transition from `open` to `closed` is recorded as a resolved signal.

### Input fields

| Field | Type | Default | Purpose |
|---|---|---|---|
| `monitorMode` | enum | `full` | Selects the enabled source groups. |
| `seedConfigs` | array | `[]` | Up to 50 explicit GPU/OS/driver/engine configurations. |
| `trackBugIds` | array | `[]` | Up to 10 GitHub issue references. |
| `arcSeries` | enum | `Arc B580` | Selects the verified hardware scope. `Arc B580 12GB` is normalized to the same scope. |
| `aiEnginesFilter` | enum array | all four engines | Restricts configuration and model output to selected engines. |
| `includeAssessment` | boolean | `true` | Adds a cautious verdict and evidence list. |
| `includeUnchangedBugs` | boolean | `true` | Includes unchanged tracked issues in the output. |
| `modelQuery` | string | empty | Matches a model name or alias such as `minimax h3 video`, `llama3.2`, or `qwen2.5`. |

Each `seedConfigs` item requires `gpu`, `os`, `driver`, `aiEngine`, `engineVersion`, and `modelFormat`. Optional fields include `flags`, `customNodeConflicts`, `envVars`, `source`, and `verifiedAt`. The supported evidence states are `confirmed`, `partial`, `failed`, and `unknown`; omission is equivalent to `unknown`, not `confirmed`. A valid source reference and parseable verification date are required before a result receives high confidence; invalid provenance is downgraded.

### Output records

Every default-dataset item has these common fields:

- `type`: `release`, `config`, `bug`, `model`, or `source_error`.
- `recordId`: a stable hash-based ID for deduplication across runs.
- `runId`, `runDate`, and `mode`: run metadata.
- `source`, `sourceUrl`, `sourceStatus`, `sourceUpdatedAt`, and `lastChecked`: provenance and freshness.
- `data`: the record-specific payload.

Configuration assessments use `canRun` values `yes`, `partial`, `no`, or `unknown`, plus an English reason, estimated performance, confidence, and evidence list. An omitted `works` value never produces `yes`. `EXL2` and `AWQ` are not treated as verified formats merely because another field says the stack works.

Release records distinguish what a source explicitly mentions from what remains `unverified`. A release that mentions Arc Pro B70 does not automatically claim Arc B580 support. The Intel Extension for PyTorch tag is included as a release signal, but its archived repository does not provide the Arc B580 evidence required for a positive compatibility verdict.

Bug records contain the real GitHub title, current `status`, labels, timestamps, relevance markers, and `changeType` (`new`, `updated`, or `unchanged`). The actor does not output the issue body, so usernames, local paths, tokens, and unrelated personal details are not copied into the result. Invalid references, unavailable sources, rate limits, and pull requests become `source_error` records with a code and retryability flag.

### Source and failure behavior

Live requests use bounded timeouts, retry transient HTTP failures, validate response shapes, and cache sanitized source responses in a named key-value store. Release, issue, and model records expose `data.sourceFetchedAt` and `data.sourceError`, so a cached response is explicitly marked `cached` and can be distinguished from a fresh check. A source failure is never replaced with a fabricated release or issue.

GitHub’s public API can be rate-limited, especially when many users share an egress address. User-supplied issue lookups always use unauthenticated public requests, so an Actor-level `GITHUB_TOKEN` is never sent to a caller-selected repository. For higher-volume fixed-source lookups, configure an optional `GITHUB_TOKEN` in the Actor environment. The actor does not require a token for the small public lookups used by the default tasks. Review the source terms and rate limits before scheduling high-frequency runs.

### Example tasks

1. **Assess an Ollama Arc stack** — use `dataset_only` with one Arc B580 configuration and `includeAssessment: true`.
2. **Check current Intel AI release metadata** — use `live` with an empty `modelQuery`.
3. **Look up a model identifier** — use `live` or `dataset_only` with `modelQuery: "minimax h3 video"`.
4. **Monitor an issue** — use `bugs_only` with one or more explicit GitHub issue references and `includeUnchangedBugs: false`.

### Limitations and responsible use

The verified hardware scope in this release is Arc B580 on the supplied Ubuntu stack. Other Arc series, Windows stacks, future drivers, and unreleased model combinations are not silently generalized. Release metadata can change after a run, and GitHub issue relevance is marked as evidence-based rather than guaranteed. Always test a deployment on the exact driver, model file, quantization, and runtime you intend to operate.

The actor reads public GitHub and Hugging Face endpoints. It does not scrape private repositories, bypass authentication, or make financial, legal, medical, or safety determinations. User-supplied environment variables and evidence fields are returned as part of the caller’s configuration; do not put secrets in them.

### Related Actors

- [Apify Open Source jobs scraper](https://apify.com/3hsh5ntm/open-source-jobs-scraper) for developer-job data.
- [Open Source Job Search](https://apify.com/curious_coder/open-source-job-search) for broader job-search workflows.
- [GitHub Issues](https://apify.com/marcusyeh/gitHubIssues) for general-purpose issue collection without Intel-specific assessment.

### Changelog

#### 0.2.0

- Replaced fabricated demo and fallback data with real source validation and explicit error records.
- Added canonical GitHub issue parsing, pull-request rejection, cross-run state, and resolved signals.
- Added safe tri-state evidence handling, engine/GPU filters, normalized model aliases, and live model existence checks.
- Added stable IDs, deduplication, bounded retries, normalized source caching, and per-item push/charge isolation.
- Aligned the Apify input schema, Zod parser, output schemas, README, and Store metadata.
- Added regression tests for URLs, source failures, assessment safety, model matching, and schema contracts.

# Actor input Schema

## `monitorMode` (type: `string`):

live: releases and optional model lookup; dataset\_only: supplied configurations and optional model lookup; bugs\_only: explicitly supplied GitHub issues; full: all enabled sources.

## `seedConfigs` (type: `array`):

Zero to 50 explicit AI stack configurations. A missing works value is treated as unknown, never as working.

## `trackBugIds` (type: `array`):

Up to 10 GitHub issue references in owner/repository#number or GitHub issue URL form. Pull requests and Intel-specific IDs are rejected explicitly.

## `arcSeries` (type: `string`):

The current verified scope is Intel Arc B580. Other series are not silently treated as compatible.

## `aiEnginesFilter` (type: `array`):

Restrict configuration and model results to the selected engines.

## `includeAssessment` (type: `boolean`):

Add a cautious canRun verdict, reason, performance estimate, confidence, and evidence list to configuration and model records.

## `includeUnchangedBugs` (type: `boolean`):

When false, only new or updated tracked issues are written; resolved transitions are still detected.

## `modelQuery` (type: `string`):

Search the curated model catalog by model name or alias (at least 3 characters), for example minimax h3 video or qwen2.5.

## Actor input object example

```json
{
  "monitorMode": "full",
  "seedConfigs": [],
  "trackBugIds": [],
  "arcSeries": "Arc B580",
  "aiEnginesFilter": [
    "ollama",
    "llama.cpp",
    "comfyui",
    "ipex"
  ],
  "includeAssessment": true,
  "includeUnchangedBugs": true,
  "modelQuery": ""
}
```

# Actor output Schema

## `results` (type: `string`):

Structured records with source status, evidence, confidence, and verification timestamps.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {};

// Run the Actor and wait for it to finish
const run = await client.actor("codeclouds/arcor").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {}

# Run the Actor and wait for it to finish
run = client.actor("codeclouds/arcor").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{}' |
apify call codeclouds/arcor --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,codeclouds/arcor"
        }
    }
}
```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/buxQINgvy5isSHiGf/builds/z2rx4wb8UWrCIdsh4/openapi.json