Opret multimodel CrewAI-agenter med CometAPI:

Det bliver mere interessant at bygge et multi-agent-system med CrewAI, når forskellige agenter kan bruge forskellige modeller.

En forsker kan have gavn af en hurtig og økonomisk model, en analytiker kan have brug for en stærkere modellerings- og ræsonneringsmodel, og en skribent kan kræve en model optimeret til høj kvalitet ved lang-form-generering. Traditionelt betyder tilslutning af disse agenter til forskellige udbydere, at man skal håndtere separate API-legitimationsoplysninger, endpoints, SDK’er, faktureringssystemer og udbyderspecifik konfiguration.

En renere arkitektur er at lade CrewAI styre agenter og workflow, mens CometAPI styrer modeladgangen.

CometAPI tilbyder et OpenAI-kompatibelt endpoint på https://api.cometapi.com/v1, så applikationer kan dirigere forespørgsler til modeller fra flere udbydere via et fælles API-interface. Den nuværende quick-start-dokumentation understøtter også brug af det standard OpenAI Python SDK ved at ændre API-nøglen og base-URL’en.

I denne vejledning bygger du et CrewAI-workflow med tre agenter med:

• Gemini 3.7 Flash til research
• Claude Opus 5 til analyse
• GPT-5.6 til endelig skrivning
• Én CometAPI API-nøgle
• Én API base-URL
• Modelkonfiguration pr. agent
• Begrænset fallback for forbigående fejl
• CrewAI checkpointing til produktionsgenopretning
• Sporing af token- og eksekveringsforbrug
• Server-side modelvalidering

Den vigtige arkitektoniske grænse er enkel:

CrewAI håndterer agentorkestrering. CometAPI håndterer modeladgang. Model-ID’er definerer ruting.

---

Hvad er CrewAI Multi-Agent Model Routing?

CrewAI er et Python-framework til at oprette agenter, opgaver, crews og multi-agent-workflows. Hver agent kan have sin egen LLM-konfiguration, mens Crew koordinerer, hvordan de agenter udfører opgaver og udveksler kontekst.

CrewAIs nuværende LLM-konfiguration understøtter eksplicitte indstillinger for model, api_key og base_url, herunder brugerdefinerede OpenAI-kompatible endpoints.

Det gør en multi-model-arkitektur ligetil:

                         CometAPI                            │              https://api.cometapi.com/v1                            │        ┌───────────────────┼───────────────────┐        │                   │                   │   Researcher            Analyst             Writer        │                   │                   │ Gemini 3.7 Flash      Claude Opus 5         GPT-5.6

Agenterne forbliver adskilte fra et logisk perspektiv, men deres modeladgang er centraliseret.

Det er noget andet end at sige, at alle modeller er udskiftelige. Et OpenAI-kompatibelt API giver et fælles forespørgselsinterface; det garanterer ikke identiske kontekstgrænser, værktøjsunderstøttelse, styring af ræsonnering, outputadfærd, latenstid eller pris.

Den skelnen er vigtig ved design af produktionsruting.

---

Hvorfor bruge CometAPI med CrewAI?

Fordelen er ikke, at CrewAI pludselig bliver et multi-udbyder-framework. CrewAI understøtter allerede flere LLM-udbydere.

Fordelen er, at modeladgang kan konsolideres bag ét API-lag.

Uden et samlet API-lag kan et workflow med tre agenter se sådan ud:

Med CometAPI:

CometAPIs nuværende quick-start-dokumentation beskriver dets endpoint som en drop-in-erstatning for OpenAI API base-URL’en og oplister modeller fra flere udbydere via samme tjeneste.

Dette giver applikationen en nyttig opdeling:

CrewAI

• Definerer agentroller
• Definerer opgaver
• Videregiver kontekst
• Styrer eksekvering
• Håndterer agent-iterationer
• Håndterer orkestrering på crew-niveau

CometAPI

• Leverer et fælles modeladgangslag
• Centraliserer API-autentificering
• Giver modelruting via model-ID’er
• Giver applikationen ét API-endpoint
• Giver centraliseret forbrugs- og faktureringsindsigt

---

Hvad bygger dette CrewAI-workflow?

Eksemplet opretter tre sekventielle agenter.

Dette er en eksempelruting, ikke en benchmarkrangering.

Den rigtige model til din agent afhænger af:

• opgavens kompleksitet
• påkrævet kontekstlængde
• brug af værktøjer
• krav til struktureret output
• latenstid
• pålidelighed
• token-omkostning
• outputkvalitet
• applikationsspecifikke evalueringsresultater

En nyttig tommelfingerregel er:

Vælg en model til det job, agenten udfører, ikke blot ud fra udbyderen.

---

Hvilken model bør hver CrewAI-agent bruge?

I dette eksempel følger modeltilknytningen en enkel strategi for omkostninger versus kapabilitet.

Forsker: Gemini 3.7 Flash

Research involverer ofte behandling af relativt store mængder information og at producere et kompakt mellemresultat.

En hurtig model kan derfor være nyttig til researchopgaver med høj volumen.

"researcher": "gemini-3.7-flash"

Analytiker: Claude Opus 5

Analytikeren har en smallere, men mere ræsonneringstung rolle. Den modtager research-output og omsætter det til en anbefaling.

"analyst": "claude-opus-5"

Skribent: GPT-5.6

Den sidste agent omdanner research og analyse til en udviklerrettet beslutningsmemo.

"writer": "gpt-5.6"

Det vigtige er ikke netop disse tre tildelinger. Din applikation bør evaluere kandidater mod repræsentative opgaver før fastlæggelse af rutingpolitikken.

---

Hvad skal du have, før du starter?

Du skal bruge:

• Python 3.10+
• CrewAI
• OpenAI Python SDK-kompatibilitet
• python-dotenv
• En CometAPI API-nøgle
• De model-ID’er, du vil bruge

CometAPIs nuværende Python-integration understøtter det OpenAI-kompatible API, og den officielle CometAPI Python-pakke dokumenterer COMETAPI_KEY og COMETAPI_BASE_URL som miljøbaserede konfigurationsmuligheder.

Standard-endpointet er:

https://api.cometapi.com/v1

Før du deployer, skal du bekræfte, at dine valgte model-ID’er er tilgængelige og understøtter det endpoint og de parametre, der kræves af dit CrewAI-workload. Modelkataloger og priser kan ændre sig.

---

Hvordan installerer du CrewAI og afhængighederne?

Opret et nyt Python-miljø:

python -m venv .venv

Aktivér det:

source .venv/bin/activate

På Windows:

.venv\Scripts\Activate.ps1

Installer derefter afhængighederne:

pip install "crewai[openai]" openai python-dotenv

Det er bevidst at bruge openai eksplicit, fordi fallback-implementeringen nedenfor importerer OpenAI SDK-undtagelsesklasser direkte.

I produktion bør du pinne de versioner, du tester, fremfor at stole på flydende seneste versioner.

For eksempel:

crewai==YOUR_TESTED_VERSIONopenai==YOUR_TESTED_VERSIONpython-dotenv==YOUR_TESTED_VERSION

CrewAIs LLM-lag er i aktiv udvikling, så den præcise konstruktion og udbyderkonfiguration bør kontrolleres i forhold til den CrewAI-version, din applikation bruger. Den nuværende CrewAI-dokumentation understøtter konfiguration af en LLM med en brugerdefineret base_url og API-nøgle.

---

Hvordan konfigurerer du CometAPI API-nøglen?

Opret en .env-fil:

COMETAPI_KEY=your_cometapi_keyCOMETAPI_BASE_URL=https://api.cometapi.com/v1

Indlæs disse værdier i Python:

import osfrom dotenv import load_dotenvload_dotenv()COMETAPI_KEY = os.environ["COMETAPI_KEY"]COMETAPI_BASE_URL = os.getenv(    "COMETAPI_BASE_URL",    "https://api.cometapi.com/v1",)

Commit aldrig .env til Git.

Tilføj den til .gitignore:

.env.venv/__pycache__/

API-nøglen bør forblive en serversidelegitimation. CometAPIs nuværende quick-start-vejledning anbefaler ligeledes at gemme nøglen i miljøvariabler fremfor i kildekoden.

---

Hvordan forbinder du CrewAI til CometAPI?

CrewAIs LLM-objekt kan modtage et modelnavn, API-nøgle og brugerdefineret base-URL.

Opret en helper:

from crewai import LLMdef cometapi_llm(model_id: str) -> LLM:    return LLM(        model=model_id,        base_url=COMETAPI_BASE_URL,        api_key=COMETAPI_KEY,        timeout=60.0,        max_retries=0,    )

Dette er at foretrække frem for at indlejre den samme konfiguration separat i hver agent.

Hver agent behøver nu kun et model-ID:

research_llm = cometapi_llm("gemini-3.7-flash")analysis_llm = cometapi_llm("claude-opus-5")writing_llm = cometapi_llm("gpt-5.6")

Hvorfor sætte max_retries=0?

Årsagen er kontrol over fallback.

Hvis den underliggende LLM-klient automatisk genprøver, og din applikation også implementerer fallback, kan én fejl blive til flere skjulte forespørgsler, før fallback-logikken udføres.

Til en vejledning med eksplicit ruting er det renere at lade applikationen beslutte, hvornår der skal genprøves eller skiftes model.

---

Hvordan definerer du modelrutingpolitikken?

Hold ruting uden for dine prompts:

PRIMARY_MODELS = {    "researcher": "gemini-3.7-flash",    "analyst": "claude-opus-5",    "writer": "gpt-5.6",}FALLBACK_MODELS = {    "researcher": "gpt-5.6",    "analyst": "gpt-5.6",    "writer": "gemini-3.7-flash",}

Dette skaber en klar konfigurationsgrænse.

Du kan senere flytte den samme mapping til:

• miljøkonfiguration
• YAML
• JSON
• en database
• feature flags
• en intern modelruting-tjeneste

uden at omskrive agentprompter.

---

Hvordan bygger du de tre CrewAI-agenter?

Opret ét LLM-objekt per agent.

from crewai import Agentdef build_agents(model_map: dict[str, str]):    researcher = Agent(        role="Market Researcher",        goal="Collect the facts needed to answer the topic",        backstory=(            "You create concise, source-aware research briefs "            "and clearly separate facts from assumptions."        ),        llm=cometapi_llm(model_map["researcher"]),        max_iter=3,        allow_delegation=False,    )    analyst = Agent(        role="Product Analyst",        goal="Turn research into a defensible recommendation",        backstory=(            "You identify evidence, assumptions, risks, "            "and trade-offs before making recommendations."        ),        llm=cometapi_llm(model_map["analyst"]),        max_iter=3,        allow_delegation=False,    )    writer = Agent(        role="Technical Writer",        goal="Produce a concise technical decision memo",        backstory=(            "You write clear technical explanations "            "without unnecessary marketing language."        ),        llm=cometapi_llm(model_map["writer"]),        max_iter=3,        allow_delegation=False,    )    return researcher, analyst, writer

Modeltilknytningen er nu helt uafhængig af agentens rolledefinition.

Det er det, der gør modelruting praktisk.

---

Hvordan forbinder du agenterne med sekventielle opgaver?

Opret tre opgaver:

from crewai import Taskdef build_tasks(researcher, analyst, writer):    research_task = Task(        description=(            "Research this topic: {topic}. "            "Return the key facts, uncertainties, "            "and relevant sources that the analyst should consider."        ),        expected_output=(            "A compact research brief containing facts, "            "uncertainties, and source references."        ),        agent=researcher,    )    analysis_task = Task(        description=(            "Using the research brief, analyze {topic}. "            "Identify the strongest conclusion and explain "            "the major trade-offs."        ),        expected_output=(            "A decision outline with evidence, "            "assumptions, risks, and trade-offs."        ),        agent=analyst,        context=[research_task],    )    writing_task = Task(        description=(            "Write a concise technical decision memo about {topic}. "            "State the recommendation early and preserve "            "important caveats."        ),        expected_output="A polished technical decision memo in Markdown.",        agent=writer,        context=[research_task, analysis_task],    )    return research_task, analysis_task, writing_task

Afhængighedskæden er:

Topic  ↓Research  ↓Analysis  ↓Final memo

Analytikeren modtager research-opgavens output, mens skribenten modtager både research- og analyse-kontekst.

---

Hvordan bygger du crewet?

Kombinér agenter og opgaver:

from crewai import Crew, Processdef build_crew(model_map: dict[str, str]) -> Crew:    researcher, analyst, writer = build_agents(model_map)    research_task, analysis_task, writing_task = build_tasks(        researcher,        analyst,        writer,    )    return Crew(        agents=[researcher, analyst, writer],        tasks=[            research_task,            analysis_task,            writing_task,        ],        process=Process.sequential,        verbose=True,    )

Nu er modelruting fuldstændig konfigurationsstyret.

At ændre:

"researcher": "gemini-3.7-flash"

til en anden understøttet model kræver ikke ændringer i research-prompten eller opgavebeskrivelsen.

---

Hvordan bør CrewAI-modelfallback fungere?

Her kræver en produktionsorienteret implementering mere omtanke.

En almindelig fejl er:

Any error   ↓Switch model

Det er for aggressivt.

For eksempel bør disse fejl generelt ikke udløse modelfallback:

400 Bad Request401 Unauthorized403 Forbidden404 Not Found422 Validation Error

At skifte model vil ikke rette en ugyldig API-nøgle eller en forkert formateret forespørgsel.

Fallback er mere passende for midlertidige fejl såsom:

408 Request Timeout429 Rate Limit500 Internal Server Error502 Bad Gateway503 Service Unavailable504 Gateway TimeoutConnection errorTimeout

Fallback-politikken bør derfor være:

Genprøv eller skift model kun for afgrænsede, forbigående fejl og kun når fallback-modellen understøtter den samme forespørgselkontrakt.

---

Hvordan opdager du fejl, der kan genprøves?

Du kan bruge OpenAI SDK’ets fejlk­lasser:

from collections.abc import Iteratorfrom openai import (    APIConnectionError,    APIStatusError,    APITimeoutError,)def exception_chain(error: BaseException) -> Iterator[BaseException]:    current: BaseException | None = error    seen: set[int] = set()    while current is not None and id(current) not in seen:        seen.add(id(current))        yield current        current = (            current.__cause__            or current.__context__        )def should_fallback(error: BaseException) -> bool:    for current in exception_chain(error):        if isinstance(            current,            (APIConnectionError, APITimeoutError),        ):            return True        if isinstance(current, APIStatusError):            return (                current.status_code in {408, 429}                or current.status_code >= 500            )    return False

Dette udelukker bevidst 400-niveau konfigurationsfejl bortset fra 408 og 429.

---

Skal du genprøve hele crewet eller kun den fejlede agent?

Der er to forskellige fallback-strategier.

Fallback på crew-niveau

Den simpleste implementering er:

Start crew   ↓failure   ↓change routing   ↓run crew again

Dette er let at forstå, men kan gentage fuldførte opgaver.

For eksempel:

Research → completedAnalysis → completedWriter → failed

En fuld kickoff()-genkørsel kan udføre:

Research → againAnalysis → againWriter → fallback

Det øger:

• token-forbrug
• latenstid
• API-omkostninger
• potentielle sideeffekter

Gendannelse på opgave-niveau

Et produktionsworkflow bør i stedet lave checkpoint af fuldført arbejde:

Research   ↓checkpoint   ↓Analysis   ↓checkpoint   ↓Writer fails   ↓retry writer with fallback

CrewAI tilbyder i øjeblikket checkpointing, der gemmer eksekveringstilstand og gør det muligt at genoptage en kørsel efter en fejl. Den dokumenterede checkpoint-adfærd springer fuldførte opgaver over og fortsætter nedstrøms arbejde fra den gemte tilstand.

Dette er den bedre arkitektur for dyre eller sideeffektproducerende workflows.

---

Hvordan tilføjer du CrewAI checkpointing?

For produktionsworkflows skal du aktivere checkpointing på crewet:

crew = Crew(    agents=[researcher, analyst, writer],    tasks=[        research_task,        analysis_task,        writing_task,    ],    process=Process.sequential,    checkpoint=True,    verbose=True,)

CrewAIs checkpointing-system kan gemme eksekveringstilstand efter opgavefuldførelse og gendanne crewet fra et checkpoint.

For eksempel kan en gendannet kørsel bruge:

from crewai import CheckpointConfigresult = crew.kickoff(    from_checkpoint=CheckpointConfig(        restore_from="./.checkpoints/checkpoint.json",    ))

Den præcise checkpoint-konfiguration bør følge den CrewAI-version, dit projekt bruger.

Det vigtige arkitektoniske punkt er:

Checkpoint først, fallback derefter.

Dette forhindrer, at en midlertidig modelfejl tvinger dyrt fuldført arbejde til at køre igen.

---

Hvordan implementerer du en simpel begrænset fallback?

Til en vejledning kan du stadig demonstrere en simpel fallback på crew-niveau.

def run_with_fallback(topic: str):    routes = [        PRIMARY_MODELS,        {            **PRIMARY_MODELS,            "writer": FALLBACK_MODELS["writer"],        },        {            **PRIMARY_MODELS,            "analyst": FALLBACK_MODELS["analyst"],            "writer": FALLBACK_MODELS["writer"],        },    ]    last_error = None    for attempt, model_map in enumerate(routes, start=1):        try:            crew = build_crew(model_map)            result = crew.kickoff(                inputs={"topic": topic}            )            return result, model_map        except Exception as error:            last_error = error            if not should_fallback(error):                raise            if attempt == len(routes):                raise            print(                f"Transient failure on attempt {attempt}. "                f"Trying bounded fallback route.",                flush=True,            )    raise RuntimeError(        "Crew execution failed after all fallback routes."    ) from last_error

Bemærk den vigtige forskel:

Dette påstår ikke, at den fejlede agent er identificeret.

Det er en begrænset fallback-strategi på crew-niveau.

For små tilstandsløse workflows kan dette være acceptabelt. For produktionsworkflows med dyr research, værktøjer eller sideeffekter skal du bruge checkpoint-baseret gendannelse.

---

Hvordan sporer du CrewAI token-forbrug?

Forbrugssporing bør være en del af rutinglaget, ikke en eftertanke.

I slutningen af kørslen inspiceres CrewAI-resultatet:

result, selected_models = run_with_fallback(topic)print("Selected models:")print(selected_models)print("Final result:")print(result.raw)print("Usage:")print(result.token_usage)

De præcise tilgængelige forbrugsfelter kan afhænge af CrewAI-version og eksekveringssti, så behandl det returnerede resultatobjekt som sandhedskilde for den version, du deployer.

En produktions-forbrugsregistrering bør ideelt indeholde:

job_idagentmodelinput_tokensoutput_tokenstotal_tokenslatency_msfallback_usedfallback_reasonstatuscreated_at

Dette lader dig besvare spørgsmål som:

Hvilken agent bruger størstedelen af budgettet?

Hvor ofte falder analytikeren tilbage?

Hvilken model har højeste latenstid?

Hvor meget koster hvert workflow?

---

Hvordan styrer du omkostninger på agent-niveau?

Multi-model-ruting er mest nyttig, når den afspejler reelle arbejdsbelastningsforskelle.

For eksempel:

Researcher→ high volume→ lower-cost modelAnalyst→ low volume→ stronger reasoning modelWriter→ medium volume→ general-purpose production model

Du kan også begrænse omkostninger gennem agentkonfiguration.

For eksempel:

max_iter=3

afgrænser agentens iterat­ionsløkke. Det bør ikke tolkes som en hård grænse på præcis tre API-kald eller tre token-budgetter.

Yderligere kontroller omfatter:

• begrænsning af opgavekontekst
• opsummering af mellemoutputs
• caching af gentagelig research
• begrænsning af maksimal inputstørrelse
• begrænsning af maksimalt output-tokenantal hvor understøttet
• begrænsning af værktøjskald
• fastsættelse af brugerbudgetter
• fastsættelse af workflow-budgetter
• sporing af fallback-frekvens

---

Hvordan validerer du modeller før deployment?

Hardcod ikke model-ID’er for evigt.

En model kan blive:

• utilgængelig
• omdøbt
• udfaset
• begrænset
• ændret i kapabilitet
• ændret i pris
• inkompatibel med en parameter, din applikation bruger

CometAPI leverer et modelkatalog-endpoint, der kan forespørges programmæssigt, mens dets offentlige modelkatalog kan bruges til menneskelig modelopdagelse.

Et deployment-tjek kan se sådan ud:

curl -s \  https://api.cometapi.com/api/models \  -H "Authorization: Bearer $COMETAPI_KEY"

Valider derefter, at dine konfigurerede model-ID’er findes før deployment.

For eksempel kan din CI-proces verificere:

gemini-3.7-flash → availableclaude-opus-5    → availablegpt-5.6          → available

Gør ikke tilgængelighedstjek til en erstatning for applikationstest. At en model er til stede i et katalog betyder ikke, at hver parameter, værktøj eller outputformat, som din CrewAI-agent bruger, er understøttet.

---

Hvordan ser det komplette CrewAI-eksempel ud?

Her er en konsolideret implementering:

import jsonimport osimport sysfrom collections.abc import Iteratorfrom dotenv import load_dotenvfrom openai import (    APIConnectionError,    APIStatusError,    APITimeoutError,)from crewai import Agent, Crew, LLM, Process, Taskload_dotenv()COMETAPI_KEY = os.environ["COMETAPI_KEY"]COMETAPI_BASE_URL = os.getenv(    "COMETAPI_BASE_URL",    "https://api.cometapi.com/v1",)PRIMARY_MODELS = {    "researcher": "gemini-3.7-flash",    "analyst": "claude-opus-5",    "writer": "gpt-5.6",}FALLBACK_MODELS = {    "researcher": "gpt-5.6",    "analyst": "gpt-5.6",    "writer": "gemini-3.7-flash",}def cometapi_llm(model_id: str) -> LLM:    return LLM(        model=model_id,        base_url=COMETAPI_BASE_URL,        api_key=COMETAPI_KEY,        timeout=60.0,        max_retries=0,    )def build_crew(model_map: dict[str, str]) -> Crew:    researcher = Agent(        role="Market Researcher",        goal="Collect the facts needed to answer the topic",        backstory=(            "You create concise, source-aware research briefs "            "and distinguish facts from assumptions."        ),        llm=cometapi_llm(model_map["researcher"]),        max_iter=3,        allow_delegation=False,    )    analyst = Agent(        role="Product Analyst",        goal="Turn research into a defensible recommendation",        backstory=(            "You evaluate evidence, assumptions, risks, "            "and trade-offs."        ),        llm=cometapi_llm(model_map["analyst"]),        max_iter=3,        allow_delegation=False,    )    writer = Agent(        role="Technical Writer",        goal="Produce a concise technical decision memo",        backstory=(            "You write clear technical explanations "            "without unnecessary hype."        ),        llm=cometapi_llm(model_map["writer"]),        max_iter=3,        allow_delegation=False,    )    research_task = Task(        description=(            "Research this topic: {topic}. "            "Return the key facts, uncertainties, "            "and relevant sources."        ),        expected_output=(            "A concise research brief with facts "            "and open questions."        ),        agent=researcher,    )    analysis_task = Task(        description=(            "Using the research brief, analyze {topic}. "            "Identify the strongest conclusion and "            "explain the major trade-offs."        ),        expected_output=(            "A decision outline with evidence, "            "assumptions, risks, and trade-offs."        ),        agent=analyst,        context=[research_task],    )    writing_task = Task(        description=(            "Write a concise technical decision memo "            "about {topic}. State the recommendation early "            "and preserve important caveats."        ),        expected_output=(            "A polished technical decision memo in Markdown."        ),        agent=writer,        context=[            research_task,            analysis_task,        ],    )    return Crew(        agents=[            researcher,            analyst,            writer,        ],        tasks=[            research_task,            analysis_task,            writing_task,        ],        process=Process.sequential,        verbose=True,    )def exception_chain(    error: BaseException,) -> Iterator[BaseException]:    current = error    seen: set[int] = set()    while current is not None and id(current) not in seen:        seen.add(id(current))        yield current        current = (            current.__cause__            or current.__context__        )def should_fallback(error: BaseException) -> bool:    for current in exception_chain(error):        if isinstance(            current,            (                APIConnectionError,                APITimeoutError,            ),        ):            return True        if isinstance(current, APIStatusError):            return (                current.status_code in {408, 429}                or current.status_code >= 500            )    return Falsedef run_with_fallback(topic: str):    routes = [        PRIMARY_MODELS,        {            **PRIMARY_MODELS,            "writer": FALLBACK_MODELS["writer"],        },        {            **PRIMARY_MODELS,            "analyst": FALLBACK_MODELS["analyst"],            "writer": FALLBACK_MODELS["writer"],        },    ]    last_error = None    for attempt, model_map in enumerate(        routes,        start=1,    ):        try:            crew = build_crew(model_map)            result = crew.kickoff(                inputs={                    "topic": topic,                }            )            return result, model_map        except Exception as error:            last_error = error            if not should_fallback(error):                raise            if attempt == len(routes):                raise            print(                f"Transient failure on attempt "                f"{attempt}; trying fallback.",                file=sys.stderr,            )    raise RuntimeError(        "No model route completed the crew."    ) from last_errordef main():    topic = (        sys.argv[1]        if len(sys.argv) > 1        else (            "Should a small SaaS add "            "AI-generated meeting summaries?"        )    )    result, selected_models = (        run_with_fallback(topic)    )    output = {        "selected_models": selected_models,        "raw": result.raw,        "tasks_output": [            task.raw            for task in result.tasks_output        ],        "token_usage": str(            result.token_usage        ),    }    print(        json.dumps(            output,            indent=2,            default=str,        )    )if __name__ == "__main__":    main()

Den vigtige forbedring i forhold til den oprindelige version er, at koden ikke længere fejlagtigt antyder, at en undtagelse identificerer den præcist fejlede agent.

Det er eksplicit en begrænset fallback-implementering på crew-niveau.

Til produktion kombineres den samme rutingpolitik med CrewAI checkpointing.

---

Hvordan kører du CrewAI-workflowet?

Gem filen som:

crewai_multi_model.py

Kør derefter:

python crewai_multi_model.py \  "Should a small SaaS add AI-generated meeting summaries?"

Et vellykket svar vil indeholde information svarende til:

{  "selected_models": {    "researcher": "gemini-3.7-flash",    "analyst": "claude-opus-5",    "writer": "gpt-5.6"  },  "raw": "<final decision memo>",  "tasks_output": [    "<research output>",    "<analysis output>",    "<writing output>"  ],  "token_usage": "<usage information>"}

Det nøjagtige svar og forbrugsdata afhænger af input, modeladfærd, CrewAI-version og eksekveringssti.

Hvis en genprøvbar fejl aktiverer fallback-ruten, viser objektet selected_models den rute, der blev brugt til den crew-eksekvering.

---

Hvordan bør du designe modelruting i produktion?

En produktionsrutingpolitik bør overveje mere end modelkvalitet.

En nyttig beslutningsfunktion er:

Model Score =Quality+ Reliability+ Context Fit+ Tool Compatibility- Cost- Latency

Du kan implementere dette på flere niveauer.

Omkostningsbaseret ruting

Simple task → economical modelComplex task → premium model

Latenstidsbaseret ruting

Interactive request → fast modelBackground workflow → higher-quality model

Pålidelighedsbaseret ruting

Primary model     ↓transient failure     ↓fallback model

Opgavebaseret ruting

Research → Model AAnalysis → Model BWriting → Model CCode → Model D

Den sidste tilgang er særligt naturlig for CrewAI, fordi frameworket allerede giver hver agent en særskilt rolle.

---

Hvordan gør du fallback sikkert?

Et robust fallbacks­ystem bør håndhæve fire regler.

Ingen fallback ved autentificeringsfejl

Hvis API-nøglen er ugyldig:

401

vil det ikke hjælpe at skifte model.

Ingen fallback ved ugyldige forespørgsler

Hvis forespørgslen er ugyldig:

400422

ret forespørgslen i stedet.

Ingen uendelig fallback

Sæt en hård grænse:

MAX_FALLBACK_ATTEMPTS = 2

Et fallbacks­ystem uden grænse kan blive en dyr genprøvningsløkke.

Gør fallback-modeller forespørgselskompatible

En fallback-model skal understøtte de funktioner, din agent kræver.

For eksempel, hvis den primære agent kræver et specifikt værktøj eller struktureret-output-adfærd, skal fallback-modellen understøtte den samme kontrakt.

OpenAI-kompatibel betyder ikke funktionskompatibel.

---

Hvad er de mest almindelige CrewAI + CometAPI-fejl?

---

Hvordan adskiller du CrewAI-fejl fra model-fejl?

Denne skelnen er vigtig ved fejlfinding.

Konfigurationsfejl

Missing API keyInvalid model IDInvalid base URLUnsupported parameter

Disse bør fejle hurtigt.

Udbyder/API-fejl

401403404429500503

Disse kræver forskellig håndtering afhængigt af status.

Applikationsfejl

Agent output invalidTool returned malformed dataTask context missingSide effect failed

Disse løses ikke nødvendigvis ved at skifte model.

Et modent agentsystem bør derfor have separat håndtering for:

configuration      ↓API transport      ↓model execution      ↓agent logic      ↓tool execution      ↓application side effects

Dette er meget sikrere end en generisk:

except Exception:    use_fallback()

---

Hvordan beskytter du eksterne sideeffekter?

Fallback bliver væsentligt mere kompliceret, når agenter gør mere end at generere tekst.

Forestil dig for eksempel en agent, der:

1. opretter en databasepost
2. sender en e-mail
3. kalder et eksternt API
4. opdaterer et CRM

Hvis modellen timeout’er efter at den eksterne handling er lykkedes, kan en gentagen kørsel duplikere handlingen.

Brug:

• idempotency keys
• opgave-checkpoints
• transaktionsgrænser
• eksekverings-ID’er
• holdbar opgavetilstand
• eksplicit bekræftelse af sideeffekt

For eksempel:

job_id = crew_run_123task_id = writer_456

Gem disse identifikatorer sammen med eksterne operationer, så en genkørsel kan afgøre, om operationen allerede er sket.

---

Hvordan overvåger du multi-model CrewAI-workflows?

Som minimum, log:

workflow_idagentmodeltaskstart_timeend_timelatencystatusfallback_usedfallback_reasoninput_tokensoutput_tokenstotal_tokens

Log ikke:

API keysprivate credentialsfull sensitive promptsprivate user dataunredacted model output

For hver model, overvåg:

Pålidelighed

success ratetimeout rate5xx ratefallback rate

Performance

p50 latencyp95 latencyp99 latency

Omkostning

input tokensoutput tokenscost per taskcost per completed workflow

Kvalitet

task success ratehuman evaluationstructured-output validitytool-call success

Dette gør modelruting til et observerbart ingeniørsystem fremfor en hårdkodet præference.

---

Hvordan vælger du mellem direkte udbyder-API’er og CometAPI?

Valget afhænger af din arkitektur.

Hvis din applikation kun har brug for én udbyder og dennes native kapabiliteter, kan en direkte integration være helt fornuftig.

Hvis din CrewAI-applikation har brug for modeller fra flere udbydere og du ønsker ét adgangslag, bliver CometAPI mere attraktiv.

Det vigtige punkt er, at CometAPI ikke erstatter CrewAI.

I stedet:

CrewAIAgent orchestration       ↓CometAPIModel access       ↓Multiple models

Hvert lag har et andet ansvar.

---

Hvordan skalerer denne arkitektur?

Når først rutingpolitikken er adskilt fra agentdefinitionerne, kræver det ikke genopbygning af hele applikationen at tilføje en anden model.

For eksempel:

PRIMARY_MODELS = {    "researcher": "gemini-3.7-flash",    "analyst": "claude-opus-5",    "writer": "gpt-5.6",    "coder": "YOUR_CODE_MODEL",}

Den samme arkitektur kan derefter understøtte:

Research agentAnalysis agentCoding agentReview agentWriting agentFact-checking agent

Hver agent kan have en anden model, mens de deler det samme CometAPI-adgangslag.

Det næste skridt er at gøre ruting dynamisk.

I stedet for:

"analyst": "claude-opus-5"

kunne du til sidst bruge:

select_model(    task="analysis",    budget=budget,    latency_target=latency_target,)

Ruting-systemet kan derefter vælge blandt godkendte modeller baseret på applikationskrav.

---

Hvad er den bedste produktionsarkitektur for CrewAI + CometAPI?

For et lille workflow:

User Input   ↓CrewAI   ↓CometAPI   ↓Models

Til produktion:

                     ┌───────────────┐                     │ Model Catalog │                     └───────┬───────┘                             │                             ▼User → CrewAI → Routing Policy → CometAPI           │          │             │           │          │             ├── Gemini           │          │             ├── Claude           │          │             └── GPT           │          │           │          ▼           │     Cost / Quality /           │     Latency / Policy           │           ▼      Checkpoints           │           ▼      Usage Tracking

De vigtigste produktionskomponenter er:

1. Model-allowlist
2. Ruting pr. agent
3. Begrænsede genprøvninger
4. Opgave-checkpointing
5. Forbrugssporing
6. Omkostningskontrol
7. Modelkompatibilitetstest
8. Observabilitet
9. Idempotente sideeffekter

Den arkitektur er væsentligt mere robust end blot at tilføje en try/except omkring crew.kickoff().

---

Én CometAPI-nøgle, forskellige modeller, klarere agentroller

Den mest nyttige måde at tænke på CrewAI og CometAPI sammen er som to komplementære lag.

CrewAI definerer, hvad agenterne gør.

CometAPI definerer, hvordan de agenter får adgang til modeller.

Den opdeling gør det muligt at tildele en hurtig model til en forsker-agent med høj volumen, en stærkere ræsonneringsmodel til en analyseagent og en general purpose-model til den endelige skribent uden at vedligeholde separate udbyderintegrationer inden i workflowet.

Den simpleste implementering bruger én CometAPI-nøgle og én OpenAI-kompatibel base-URL:

https://api.cometapi.com/v1

Til produktion skal du tage arkitekturen et skridt videre: hold modelruting i konfiguration, valider modeltilgængelighed før deployment, brug begrænset fallback kun for forbigående fejl, lav checkpoints for fuldførte opgaver, og registrér model- og forbrugsmetadata for hver kørsel.

Det giver dig et langt mere holdbart mønster end blot at tilslutte CrewAI til én LLM:

CrewAI orkestrerer agenterne. CometAPI centraliserer modeladgang. Model-ID’er styrer ruting. Checkpoints beskytter fuldført arbejde. Forbrugssporing styrer omkostninger.

---

Ofte stillede spørgsmål

Kan CrewAI bruge flere AI-modeller i samme crew?

Ja. Tildel en anderledes LLM-konfiguration til hver CrewAI-agent. Hver konfiguration kan angive sin egen model, mens den bruger den samme CometAPI API-nøgle og base-URL.

Kan CrewAI forbinde til et OpenAI-kompatibelt API?

Ja. CrewAIs LLM-konfiguration understøtter en brugerdefineret base_url og API-nøgle til OpenAI-kompatible endpoints.

Med CometAPI er base-URL’en:

https://api.cometapi.com/v1

Skal jeg have separate API-nøgler til GPT, Claude og Gemini?

Når du får adgang til disse modeller via CometAPI, kan applikationen bruge CometAPI-legitimationen og endpointet i stedet for at implementere separate udbyderlegitimationer i hver CrewAI-agent.

Betyder én API-nøgle, at modellerne har identiske kapabiliteter?

Nej. API-interface kan være forenet, mens modelfunktioner forbliver forskellige. Kontekstvinduer, værktøjsunderstøttelse, parametre, outputadfærd, latenstid og priser kan variere pr. model.

Skal jeg genprøve hele CrewAI-workflowet, når én model fejler?

Kun for simple, tilstandsløse workflows. En genkørsel af hele crewet kan gentage fuldførte opgaver og øge omkostningerne. For produktionsworkflows bør du lave checkpoints af fuldførte opgaver og genoptage fra den fejlede del, hvor det er praktisk.

CrewAIs nuværende checkpointing-funktionalitet er designet til at bevare eksekveringstilstand og genoptage efter fejl.

Skal enhver CrewAI-undtagelse udløse modelfallback?

Nej. Autentificering, ugyldige forespørgsler, ugyldige model-ID’er og ikke-understøttede parametre kræver generelt konfigurationsændringer fremfor en anden model.

Fallback er bedre reserveret til begrænsede forbigående fejl som timeouts, ratelimits og midlertidige 5xx-responser.

Hvordan sporer jeg omkostningen for hver CrewAI-agent?

Registrér agentnavn, model-ID, token-forbrug, latenstid, eksekveringsstatus og fallback-information for hver opgave. Brug de resulterende data til at beregne omkostning pr. agent og workflow.

Kan jeg dynamisk ændre modellen, der er tildelt en agent?

Ja. Hold model-ID’er i en rutingkonfiguration fremfor at indlejre dem direkte i agentdefinitioner. Din applikation kan derefter vælge modeller baseret på omkostning, latenstid, opgavetype eller tilgængelighed.

Er CometAPI en erstatning for CrewAI?

Nej. De fungerer på forskellige lag. CrewAI orkestrerer agenter og opgaver, mens CometAPI leverer et forenet modeladgangslag.

Hvor kan jeg finde de nuværende CometAPI-modeller?

Brug CometAPI model directory til menneskelig modelopdagelse og model-API’et til programmæssig validering. CometAPIs nuværende quick-start-side oplister 500+ modeller på tværs af tekst-, billede-, video- og lydkategorier.

---

Kilder

• CometAPI Quick Start
• CometAPI Model Directory
• CometAPI API Documentation
• CometAPI Python SDK
• CrewAI Documentation
• CrewAI LLM Configuration
• CrewAI Checkpointing