Tech Radar - 2026-10-22 07:08

Priority Today

Anthropic ships API version 2026-10-21 with new SDK and CLI majors

On October 21 Anthropic released API version 2026-10-21 and shipped new client SDKs and the ant CLI that send it by default: Python SDK 2.0.0, TypeScript SDK 1.0.0, C# SDK 13.0.0, Go SDK 2.0.0, Java SDK 3.0.0, PHP SDK 1.0.0, Ruby SDK 2.0.0 and ant CLI 2.0.0. The new SDK and CLI versions carry breaking changes that do not depend on the API version, and they are licensed under Apache 2.0 instead of the MIT License. The same release adds enforcement_status and enforcement_actions to user profiles, so an operator can see whether Anthropic has restricted or banned one of its end customers, and adds an enforcement_status[] filter for listing profiles with an open restriction or ban, which extends the enforcement surface that landed with user profiles on October 20. Claude Code 2.1.307 shipped alongside with a /claude-api api-version command that moves Claude API code to the new version, and with a new claude_code.safety_event OpenTelemetry event emitted for every tool call that a permission rule, auto mode, a safety check, a hook or the sandbox stopped.

Why it matters: Anthropic has now separated two kinds of breakage that used to be one. The API version is a header you set once and can keep pinned, while the SDK and CLI majors carry their own breaking changes and land on their own schedule, so a routine dependency bump can change behaviour without changing anything about the API. What changed: One new API version string, eight new major SDK and CLI releases with an MIT to Apache 2.0 license change, enforcement fields and a filter on user profiles, and a documented migration path. For me: Read the migration guide before taking an SDK major, because the header and the major version are separate decisions. Claude Code users can run /claude-api api-version instead of editing headers by hand. If you resell API access or run a gateway, the enforcement fields matter more than the version, because they tell you when a single customer profile has been actioned without your API calls failing.

Tags: #topic/ai-coding #topic/ai-agents #entity/anthropic #entity/claude-code #technology/llm-api #event/api-change #relevance/developer #learning/understand

Sources:

Recursive ships Flint, a 40B mixture-of-experts coding model with 2.5B active parameters

On October 21 Recursive published Flint, a mixture-of-experts model with 40 billion total parameters that activates 2.5 billion per token, built from scratch by what Recursive calls a small team of people and agents in under four months. Recursive states that Flint leads mixture-of-experts models with fewer than 50 billion total parameters on agentic coding benchmarks including SWE-Bench Pro v2, Terminal-Bench 2.1 and SWE-Bench Verified, and that it rivals dense models of 25 to 40 billion parameters while running more than five times faster. With Recursive's own inference engine it generates more than 125 tokens per second on an M4 Pro MacBook Pro and more than 150 tokens per second on a 64GB NVIDIA RTX Spark at short contexts, up to twice as fast as comparable models. The context window goes to 512k tokens, with the recommendation to stay within 256k for the best results. Most of the model-building stack came from Recursive's Eureka Machine: architecture search moved a 35B total and 3B active baseline to 40B and 2.5B, quantization put the output layer at 4 bits with an offline distillation stage using the 16-bit model as teacher, and the resulting NVFP4 model scores within 0.7 points of the 16-bit model across Recursive's benchmarks, while kernel work produced a Metal megakernel on M4 and M5 that fuses the entire decode forward pass. Weights are on Hugging Face under Apache 2.0, and Flint works with llama.cpp, Ollama, Unsloth, LM Studio, vLLM and SGLang, with a lightweight rec engine released for M4 Pro and M5 Pro/Max. Recursive's evaluation used mini-swe-agent for the SWE-Bench runs and Terminus 2 with XML output for Terminal-Bench, with agent timeouts up to five hours, average pass@1 over at least five attempts, temperature 1.0, top-p 0.95 and top-k 20, and speed averaged over a 128k-token session with prefill excluded.

Why it matters: A 2.5B active model that competes with much larger dense models on agentic coding and runs above 125 tokens per second on a laptop changes what a local coding agent costs, and the four-month build time is a claim about how much of that pipeline is automated. What changed: New Apache 2.0 weights with a full local serving path across six runtimes and a dedicated inference engine for Apple silicon. For me: Runnable today on a Mac or a single workstation GPU, with no remote calls. Treat the benchmark numbers as Recursive's own and reproduce one task before moving a workflow, and note the caveat in the post: Flint may need more guidance than the closed-source coding models you are used to.

Tags: #topic/ai-models #topic/ai-coding #entity/recursive #technology/quantization #technology/inference #event/model-release #relevance/developer #learning/hands-on

Sources:

OpenAI adds a 12-hour prompt cache lifetime for the Responses API

OpenAI's October 20 changelog added a 12-hour prompt caching option to the Responses API, set through prompt_cache_options.ttl with the value "12h". The guide puts the economics plainly: a 30-minute cache write, the default, costs 1.25 times the uncached input-token rate, and a 12-hour write costs 2.5 times, with the note that these are total write rates rather than surcharges on top of ordinary input. Reads cost 0.1 times the ordinary input rate on most of these models and 0.05 times on GPT-6.1 Sol, and the read rate is the same for both lifetimes. A request can carry up to four cache writes, and OpenAI adds prompt_cache_options.prewarm so an application can prepare a known prefix at startup and cut time to first token on the first real request. For GPT-5.6 and later the minimum cacheable prefix is 1,024 tokens, and the request-level TTL applies to the implicit breakpoint and to explicit breakpoints that do not set their own, so one request can mix a long-lived 12-hour prefix for stable instructions with a 30-minute one for volatile session context. Upgrading valid 30-minute coverage to 12 hours is charged as a new 12-hour write with no credit for the earlier write, and "12h" sets a minimum lifetime rather than a deletion deadline.

Why it matters: Agent sessions are long-lived by nature, so a 30-minute cache means the large shared prefix gets re-written whenever a session idles past the window. A 12-hour minimum makes the long session the cheap case rather than the exception, and the mix-lifetimes option is the part that makes it usable without over-paying for volatile context. What changed: A new cache lifetime with its own write multiplier, up to four cache writes per request, prewarm for known prefixes, and a 1,024-token minimum on GPT-5.6 and later. For me: Worth it when the same large prefix is reused across hours, and the break-even is a function of reuse, so run the numbers on your own traffic rather than assuming. Remember the write is a total rate, not an extra fee, and that moving existing coverage from 30 minutes to 12 hours is billed as a new write.

Tags: #topic/ai-economics #topic/ai-agents #entity/openai #technology/llm-api #event/pricing-change #relevance/cheap #learning/hands-on

Sources:

The Unified Harness Protocol adds a harness retirement capability

The Unified Harness Protocol published version 2026-10-19 on October 19, and its single non-additive rule change is a new harness_retirement capability. The delete response now reports the affected sessions, each marked "kept" or "retired", and a restorableUntil timestamp in Unix seconds, so a client can tell whether a harness can still be brought back or has passed the point where the workspace is gone. Two error codes complete the path: harness_busy returns 409 when a harness is still in use, and invalid_input and model_not_available return 422. The release also adds created_at and completed_at to turns, introduces an input_history capability, and deprecates fallback. The base conformance suite for the version, 2026.10.19, adds case F-09, a Full-profile check that creates a harness, runs a task and deletes the harness. The memory side of the protocol is older and separate: the Memories chapter shipped in the 2026-10-04 spec, with a named memory tree, per-node grants, provider-held records, recall by meaning, and the observe, remember, forget and erase operations, which is what makes the kept and retired semantics load-bearing rather than theoretical.

Why it matters: Retirement is the operation every hosted agent product needs and every protocol has glossed over. What happens to the workspace, the transcript and the state of a harness you delete, and whether any of it can be undone, is a contract question, and putting a restore deadline on the wire is a contract rather than an implementation detail. What changed: One new capability with its own error codes, timestamps on turns, an input-history capability, one deprecation, and a new conformance case covering create, run and delete. For me: Read the retirement semantics before writing a delete path. The sessions field and restorableUntil are what tell your interface whether to offer a restore, harness_busy is the error to handle on a concurrent delete, and the conformance suite version is what you assert against in your own tests.

Tags: #topic/ai-agents #entity/unified-harness-protocol #technology/agent-memory #technology/llm-api #event/api-change #relevance/developer #learning/deep-dive

Sources:

OpenAI puts $1 billion behind coordinated vulnerability response with Patch the Planet

On October 21 OpenAI described the two-month coalition it ran against critical vulnerabilities in PHP. "Calif", an OpenAI agent, identified a critical flaw using GPT-5.6 Sol as part of the Patch the Planet initiative, and Wiz independently discovered and reported both vulnerabilities. PHP's maintainers led the fixes and the release, with OpenAI, Wiz, Cloudflare and other partners contributing research, technical support and coordination so protections could be prepared before disclosure. OpenAI published a PHP version checker as a Codex skill so operators can find potentially vulnerable versions, and committed $1 billion in subsidized Daybreak access through Daybreak for Frontline Defenders, aimed at organizations with limited security resources that protect essential services. The proposed response has five stages: validate and fix the upstream vulnerability, including adversarial testing against the patch with frontier models; give affected organizations time to act; coordinate with government partners; prepare updates across affected products; and publish guidance and support deployment. For the PHP response OpenAI says it engaged the White House's Super Intelligence Force, the Office of the National Cyber Director, CISA and international partners. On the maintainer side, OpenAI is funding Codex for OSS subscriptions for all maintainers and directly sponsoring projects such as the Rust Foundation, and open source projects can apply to Patch the Planet for hands-on support. OpenAI calls the interval between discovery and disclosure the Defender's Window and says it expects similar findings to increase sharply.

Why it matters: The money is aimed at the bottleneck, and the bottleneck is maintainer capacity rather than model capability. The interesting part is the sequence, because model-driven discovery followed by a coordinated disclosure window is a repeatable pattern rather than a one-off rescue. What changed: A published five-stage framework, a funded defender access program, a Codex skill for checking PHP versions, and direct support for maintainers. For me: If you run PHP, apply the fixes and use the Codex skill to work out which versions are affected. The framework is explicitly a proposal that OpenAI is asking the security community to argue with, so expect it to change, and watch for the same shape of programme aimed at your own language.

Tags: #topic/security #topic/ai-agents #entity/openai #technology/agent-security #event/policy-change #relevance/developer #learning/understand

Sources:

Free and Cheap Access

Vercel puts Baseten's Mammoth-1 and Elephant-1 on AI Gateway for free until October 27

On October 21 Vercel announced that Baseten's Mammoth-1 and Elephant-1 are available on AI Gateway for free until October 27. Mammoth-1 is a 27B model and Elephant-1 a 9B model, both with a 16k context window, and both return choices with probabilities and scores rather than a single answer. Vercel says Mammoth-1 ranked first on the Jev Decision Index and tied for first on the Artificial Analysis Decision Index, and the models are addressable as baseten/mammoth-1 and baseten/elephant-1 in the AI SDK, where a new experimental_decide helper calls them, and through an OpenAI-compatible Decisions API.

Why it matters: A model that returns a distribution instead of one token lets you route, threshold and abstain, and this is a two-week free window to find out whether a cheap model is good enough to run that logic. What changed: Two models on AI Gateway, free until a fixed date, with an AI SDK helper and an OpenAI-compatible endpoint. For me: Use the window to test the decisions API against a real task. The context is 16k, so this is not a long-document tool, and free access ends on October 27, after which the pricing applies.

Tags: #topic/ai-economics #topic/ai #entity/vercel #entity/baseten #technology/structured-output #event/free-tier #relevance/free-access #learning/hands-on

Sources:

Baseten's Mammoth-1 and Elephant-1 now available on AI Gateway for free

AI Coding and Agents

Glean's headless agent building reaches general availability

Glean's headless agent building is now generally available, in a blog post last updated on October 21. Developers build, test, version and publish governed Glean agents from Claude Code, Cursor, Codex and Git, and the Glean plugin writes the agent into the coding workspace as a spec.yaml for configuration plus an instructions.md for behaviour, which can then be extended with skills or subagents and kept alongside the rest of the code. Only Auto mode is supported, the published agent runs on Glean's managed runtime rather than a runtime the customer has to build, and it inherits the same knowledge graph, permissioned access across more than 275 enterprise sources and audit trail as an agent made in Glean's visual builder. The capability itself first appeared on August 31, 2026 without general availability language.

Why it matters: A headless builder changes the shape of enterprise agent work. The agent becomes a versioned artifact in source control that is reviewed and tested, rather than a configuration one person tweaks in a console, and the enterprise context arrives already attached. What changed: General availability, with a file-based spec, publishing into a managed runtime, and Auto mode as the only supported mode. For me: Worth reading the spec format even if you will never buy Glean, because spec.yaml plus instructions.md plus skills is a portable shape for defining an agent. The 275-source permissioning is what makes this an enterprise product rather than a demo, and it is the part that cannot be copied.

Tags: #topic/ai-coding #topic/ai-agents #entity/glean #technology/agent-skills #technology/agent-security #event/tool-release #relevance/developer #learning/understand

Sources:

OpenCode v2.1.2 makes free-limit recovery visible and fixes credential forwarding

OpenCode v2.1.2 shipped on October 21 with a Clear Free-Limit Recovery flow: the desktop app and the TUI now show the reset time for a free limit, restore the prompt you had submitted, and offer either an upgrade or a switch to a different model. Setting OPENCODE_DISABLE_FREE_MODELS=1 hides zero-cost models from the list. The release adds experimental.location_idle_timeout, makes the installer create ~/.zshrc or config.fish and add itself to PATH, and puts a retryAfterMs field in structured session errors. The fixes cover legacy console.opencode.ai credential forwarding, which sent requests to the old host, and locations staying loaded while sessions were waiting. v2.1.0, released on October 20, added persistent Windows PTYs, TUI todo lists behind experimental.todo and reliable long-running TUI commands, and it carries the breaking renames: providerState becomes native, the tool.native field is merged, Credential.Key.configuration is removed, compaction keeps an ID under metadata.keepID, providerContext becomes native.messages and the session.compacted event is gone. The 2.x packages ship under the @opencode scope while the legacy opencode-ai package stays on 1.19.3.

Why it matters: The 2.x renames are what to read before upgrading, because they break config files and plugins without a runtime error, and the package scope change means an old install command keeps quietly handing you 1.x. What changed: Free-limit recovery with prompt restore, a new environment flag, an idle-timeout setting, installer PATH handling and structured retry timing, on top of the 2.1.0 renames and Windows PTY support. For me: Upgrade deliberately rather than automatically, and grep your config for providerState, providerContext and session.compacted before you do. If you hit a free limit, the recovery flow is a reason to move to 2.x, and OPENCODE_DISABLE_FREE_MODELS=1 is the switch to flip if you would rather the model list stopped advertising zero-cost models.

Tags: #topic/ai-coding #topic/developer-tools #entity/opencode #technology/terminal-ui #event/tool-release #relevance/developer #learning/hands-on

Sources:

OpenCode changelog

Models and Capabilities

Ornith-1.5-122B is a 122B mixture-of-experts model that serves on one 80GB GPU

Ornith published Ornith-1.5-122B under MIT, with the model card uploaded and revised through October 21. It is a 122B mixture-of-experts model designed to serve on a single 80GB GPU with a context window of up to 262,144 tokens, extendable with YaRN scaling applied statically, and a quantized Ornith-1.5-122B-Mobile variant targets edge devices. The change from Ornith-1.0 is the training loop rather than the weights: instead of a fixed set of human-written tasks and hand-built harnesses, the system jointly optimises task generation, scaffold construction and solution rollouts, so the model proposes progressively harder tasks near its own capability frontier, generates the scaffold for each task, produces solution rollouts, and propagates reward back through all three stages. The card reports 84.5 on SWE-bench Verified with anti-hacking safeguards, 76.9 on SWE-bench Pro without hacks, 81.2 on Terminal-Bench 2.1, 80.0 on CyberGym and 51.2 on NL2Repo, and it gives the harness for each: OpenHands with a 256k window, temperature 1.0 and top-p 0.95 for the SWE-bench family, Claude Code 2.1.126 with a 131,072 max_new_tokens for Terminal-Bench averaged over five runs, and a 400k context with 48k output for NL2Repo.

Why it matters: A model that writes its own tasks and its own scaffold, with reward propagated back through all three, is the mechanism behind the self-improvement thread, and this release is one where the weights and the recipe are both public. What changed: A new MIT 122B MoE release with a single-GPU serving recipe, a documented evaluation protocol including the anti-hacking safeguards, and a mobile variant. For me: The serving recipe is the practical part: vllm serve or SGLang with --context-length 262144 on one 80GB card. Reproduce one benchmark before believing the table, and note that the comparison models are named and the safeguards are described, which is more than most model cards give you.

Tags: #topic/ai-models #topic/ai-coding #entity/ornith #technology/inference #technology/agent-evaluation #event/model-release #relevance/developer #learning/understand

Sources:

Infrastructure and DevOps

Edera 1.13 collapses install to one Helm chart and adds ARM64 Graviton

Edera 1.13, published on October 21, replaces the multi-step install with a single Helm chart, moves the default image toward Bottlerocket for production use, and adds ARM64 support on AWS Graviton with Xen SystemReady, DMA isolation and Graviton4 supported from day one. The release also brings KVM snapshot and restore along with suspend and resume, SPIFFE and SPIRE attestation with image signature verification, and Kubernetes-native memory accounting through Dynamic Resource Allocation. The centre of gravity of the release is the operating path rather than new capability: one install, an immutable host image, and an answer to which workload was running.

Why it matters: Self-hosted AI infrastructure survives or dies on the boring path, and a single chart plus an immutable image plus attestation is what turns a demo into something an operator can leave running unattended. What changed: One Helm install path, Bottlerocket by default, ARM64 on Graviton, KVM snapshots, workload attestation, and DRA-based memory accounting. For me: Relevant if you run Kubernetes-based inference on your own hardware, and the ARM64 path matters specifically for Graviton hosts. Attestation and memory accounting are the two to check against the gaps you already have.

Tags: #topic/devops #entity/edera #entity/kubernetes #technology/containerization #technology/infrastructure-as-code #event/tool-release #relevance/infrastructure #learning/hands-on

Sources:

Edera 1.13: single Helm install, ARM64 Graviton, KVM and more

Agent Capability

Meta's thin orchestrator keeps domain logic out of the router

Meta's engineering blog of October 19 describes a thin orchestrator: about 1,300 lines that route more than 20 workflows to 14 specialised agents, with no domain work happening in the router at all. The design has two layers, a deterministic orchestrator above 14 subagents with isolated context, and a fixed seven-step protocol in which only step six uses LLM reasoning. Workflows are written as deterministic state machines, so Column Onboarding runs Schema, Validation, Population and Testing, and Event Onboarding and Pipeline Migration are templates of the same kind, which means a new use case is a new template rather than new agent code. More than 25 knowledge files load on demand. Meta's numbers: preparing a configuration took three to four days by hand, about a day with an earlier config-driven system, and under an hour with the thin orchestrator, and roughly two thirds of changes land without significant human edits. The failure mode it names is the single agent that holds all the domain knowledge, which degrades past a context threshold as knowledge from one task contaminates another. Meta also reports 70 to 80 percent success with per-task manual prompts against 10 to 20 percent without them.

Why it matters: The claim worth taking is that the router is the wrong place to put domain logic. Making the orchestration a deterministic state machine and pushing knowledge into the agent that needs it is a design you can copy into a multi-agent system you already have, without adopting a framework. What changed: Nothing to install, but a published architecture with the numbers behind it, including the context-contamination limit of the single-agent alternative. For me: The lesson applies to anything you have already built as one agent with a growing prompt. Move the procedure into a state machine, the knowledge into the agent that needs it, and treat the two-thirds-unchanged figure as the metric to aim for rather than the throughput.

Tags: #topic/ai-agents #entity/meta #technology/agent-orchestration #technology/multi-agent #event/technical-demo #relevance/ai-workflow #learning/deep-dive

Sources:

Thin orchestrator: a new AI agent architecture

Developer Tooling

iFixAi v4.2.1 audits an agent's own behaviour in under two minutes

iFixAi published v4.2.1, named "V11 inspection", on October 21, following v4.2.0 on October 15. The project audits AI agents independently, and the question it is built to answer is whether the agent is doing what it is supposed to do, with its own claim being a verdict in under 120 seconds, run by a human or by the agent itself. The repository is Apache 2.0 with 31,577 stars and 1,611 forks, and it carries the topics agent evaluation, AI governance, the EU AI Act, ISO 42001, NIST AI RMF, OWASP LLM and prompt injection, alongside hallucination detection and risk assessment, which is what makes it read as a governance instrument that happens to run agents rather than a benchmark harness.

Why it matters: Agent evaluation is still largely manual, and a tool that produces a compliance-shaped verdict in two minutes has a completely different cost structure from an audit cycle. For anyone shipping agents to customers, the verdict format is the deliverable. What changed: A new inspection version on a project that now spans compliance frameworks, agent evaluation and agent security in one tool. For me: The question to ask is what "independent" means here and whether the audit can run against an agent you do not control, since that decides whether it is useful to you or only to a compliance function. Worth a look if you ship agents to customers.

Tags: #topic/ai-agents #topic/developer-tools #entity/ifixai #technology/agent-evaluation #technology/agent-security #event/tool-release #relevance/developer #learning/hands-on

Sources:

Open Source Momentum

Strata serves Qwen3.8-Flash-Next on consumer hardware with local OpenAI and Anthropic APIs

Strata is a one-click install for Windows and Linux that runs Qwen3.8-Flash-Next on consumer hardware, serving an OpenAI and Anthropic compatible API on localhost with no account and no telemetry. The repository is MIT licensed, was created on September 24, 2026 and has 29,966 stars and 3,186 forks, with a run of releases through the last week: v0.1.43 and v0.1.43.1 on October 11 and 12, v0.1.44 and v0.1.44.1 on October 13 and 14, v0.1.45 on October 17, v0.2.0-beta on October 19, v0.2.1 on October 20 and v0.2.2 on October 21. What the forks show is where the project is heading: one runs the same model in NVFP4 on a single RTX 20-series card with all experts held in system memory, and another reads Strata's GGUF files from Apple silicon through an MLX engine and speaks its line protocol.

Why it matters: Local inference used to mean whatever fitted in your memory budget. A project whose forks are squeezing a 125B model onto a single consumer card is evidence that the constraint moved, and the OpenAI and Anthropic compatible endpoints mean existing tools can point at it unchanged. What changed: Release cadence through the week up to v0.2.2 on October 21, with the community extending it to single-card NVFP4 and Apple silicon paths. For me: Worth a look if you want a local endpoint that speaks the APIs your tools already use, with no account to create. Read the README for the actual hardware floor before planning around it, and note that the 125B path is what the forks are doing, not what the default install does.

Tags: #topic/open-source #topic/ai-models #entity/strata #technology/quantization #technology/inference #event/github-traction #relevance/self-hosting #learning/hands-on

Sources:

New Concepts

Context interference

Context interference is the name for a failure mode that appears when one agent's accumulated context contaminates the work of another: every additional task widens the surface where stale state, borrowed conclusions and wrong assumptions leak into the next answer, so a single agent's accuracy falls as the workload grows instead of holding flat. Meta's thin orchestrator describes the limit from the architecture side, where one agent holding all the domain knowledge crosses a context threshold and knowledge from one task contaminates another, which is the argument for splitting work into subagents with isolated context. The measurement side comes from a clinical-scale evaluation, "Orchestrated multi agents sustain accuracy under clinical-scale workloads compared to a single agent" in npj Health Systems, where an orchestrated multi-agent arrangement holds 90.6 percent accuracy at five tasks and falls to 65.3 percent at 80 tasks, while a single agent falls from 73.1 percent to 16.6 percent over the same range, with the divergence appearing past ten tasks, and the multi-agent arrangement using up to 65 times fewer tokens. The term is worth having because the two failure modes look identical from the outside, an agent that has quietly stopped being right, and the fix is structural rather than a better prompt.

Tags: #topic/ai-agents #topic/ai-research #technology/context-interference #event/research-breakthrough #relevance/discovery #learning/understand

Sources:

Tag Index

Topic: #topic/ai #topic/ai-agents #topic/ai-coding #topic/ai-economics #topic/ai-models #topic/ai-research #topic/developer-tools #topic/devops #topic/open-source #topic/security

Entity: #entity/anthropic #entity/baseten #entity/claude-code #entity/edera #entity/glean #entity/ifixai #entity/kubernetes #entity/meta #entity/openai #entity/opencode #entity/ornith #entity/recursive #entity/strata #entity/unified-harness-protocol #entity/vercel

Technology: #technology/agent-evaluation #technology/agent-memory #technology/agent-orchestration #technology/agent-security #technology/agent-skills #technology/containerization #technology/context-interference #technology/infrastructure-as-code #technology/inference #technology/llm-api #technology/multi-agent #technology/quantization #technology/structured-output #technology/terminal-ui

Event: #event/api-change #event/free-tier #event/github-traction #event/model-release #event/policy-change #event/pricing-change #event/research-breakthrough #event/technical-demo #event/tool-release

Relevance: #relevance/ai-workflow #relevance/cheap #relevance/developer #relevance/discovery #relevance/free-access #relevance/infrastructure #relevance/self-hosting

Learning: #learning/deep-dive #learning/hands-on #learning/understand