aws·Aug 6, 2026·3 min readCurated summary

Runtime instances: persistent compute for production AI agents on Amazon Bedrock AgentCore | Amazon Web Services

Amazon Bedrock AgentCore Runtime Instances provides persistent, managed compute for production AI agents that need more than short-lived invocations. It supports multi-day workflows, shared state, GPU acceleration, multi-agent collaboration, and direct OS access while AWS manages the underlying EC2 infrastructure. Runtime Instances complements AgentCore’s lightweight microVMs, enabling teams to combine fast-scaling orchestration with persistent worker environments. ## Why Persistent Compute Matters - Production agents often run for hours or days and must preserve state across workflow steps. - Complex systems may require: - Collaboration between multiple agents - Shared files and context - GPU acceleration - Direct operating-system access - Continuous execution across multiple days - Previously, teams had to provision EC2 instances, configure networking, manage sessions and scaling, and build monitoring themselves. ## What Runtime Instances Provides - AWS-managed EC2 infrastructure for hosting multiple agents in one runtime. - Shared sessions that persist for up to 14 days. - Separate dependencies and artifacts for each deployed agent. - GPU-capable infrastructure for compute-intensive workloads. - Session stop and restart capabilities to reduce idle costs. - Support for zip packages and container images. - Compatibility with frameworks such as CrewAI, LangGraph, LlamaIndex, and Strands. - Integration with existing AgentCore APIs, identity controls, and observability. - Persistent knowledge storage through Amazon EBS and AgentCore Memory. ## Combining MicroVMs and Runtime Instances - Runtime microVMs remain useful for lightweight orchestrator agents that need rapid scaling. - Runtime Instances are better suited to persistent, resource-intensive workers. - An orchestrator can: - Route tasks to specialized agents - Make API calls - Aggregate results - Instance-based workers can handle tasks such as code compilation, security scanning, or GUI automation while retaining local state. ## Shared-Filesystem Agent Example The demonstration uses two Strands Agents applications: - A code writer: - Generates Python code from a natural-language task. - Saves the result as `code.py` in a session-specific shared directory. - A code reviewer: - Reads the writer’s file from the same filesystem. - Reviews it for bugs, style issues, and suggestions. - Both applications use: - An `@app.entrypoint` decorator - A selected Bedrock model - The session ID to identify shared storage - Because both agents share the host filesystem, they exchange artifacts without API calls or explicit data transfer. ## Deployment Workflow ### Create a Capacity Provider - Select the operating system, allowed EC2 instance types, VPC, subnets, and security groups. - The example uses: - Linux 64-bit ARM - `c7g.2xlarge` - 8 vCPUs and 16 GiB of memory - A default `gp3` volume - AgentCore creates or assigns the required infrastructure role and instance profile. - Once active, most capacity provider settings cannot be changed, so configuration should be verified beforehand. ### Create a Runtime and Deploy an Agent - Create a runtime using the **Instances** compute type. - Associate it with the capacity provider. - Upload the agent package to Amazon S3. - Specify the language runtime, such as Python 3.13, and the entry-point file containing `@app.entrypoint`. - Deployment can be performed through the AWS Management Console, AgentCore CLI, AWS CLI, or infrastructure as code. Runtime Instances are a strong fit for agents with long-running, stateful, collaborative, or compute-heavy workloads. Use them alongside microVMs when a system needs both elastic orchestration and persistent worker infrastructure, while relying on EBS or AgentCore Memory for state that must outlive individual sessions.

Read original(opens in new tab)

PythonMulti Agent SystemsAmazon Bedrock AgentcoreAws Ec2+2

cloudflare·Aug 3, 2026·2 min readCurated summary

Workers RPC now works across Python and JavaScript

Workers RPC, originally based on Cap’n Proto RPC, is expanding from JavaScript-only communication to seamless JavaScript–Python interoperability through Cap’n Web. Workers can call methods, pass objects and functions, propagate exceptions, and use native language types without schemas, dependencies, or significant performance overhead. The result is a multi-language system that can be used much like a local library. ## Cross-Language RPC in Workers - JavaScript Workers can call Python Worker methods, and Python Workers can call TypeScript methods. - Objects, functions, streams, and live remote objects can be passed between Workers. - A Service binding is the only required configuration. - RPC calls return promises in JavaScript/TypeScript and futures in Python. - Exceptions propagate back to the call site. - Most calls run in the same thread, providing near-zero overhead compared with local execution. - The implementation is open source through `workerd` and `workers-runtime-sdk`. ## Automatic Type Conversion - RPC supports Structured Cloneable values as parameters and return values. - Common types are converted into native equivalents, such as JavaScript `Date` to Python `datetime`. - JavaScript objects can correspond to Python dictionaries, while Python keyword arguments can represent JavaScript options objects. - Functions can cross the language boundary; invoking a transferred function creates a reverse RPC call to its original Worker. ## Pyodide’s Role - Python Workers use Pyodide, a WebAssembly-compiled CPython runtime. - Pyodide’s Foreign Function Interface translates common values automatically: - Python `int` and `float` → JavaScript `Number` - Python `bool` → JavaScript `Boolean` - Python `dict` → JavaScript `Object` - Python `list` → JavaScript `Array` - Types that cannot be directly converted, such as custom classes and functions, are represented by proxies that forward property access and method calls. ## Handling Worker-Specific Objects - Standard Web API objects such as `Request`, `Response`, `Blob`, and `File` do not have direct Python equivalents. - Pyodide initially exposes these values as JavaScript proxy objects. - Although proxies remain functional, they expose JavaScript implementation details to Python developers and make the API less natural. - The project therefore requires an additional conversion layer to provide Python-friendly representations of Cloudflare Workers objects. ## Practical Implication Cross-language Workers RPC lets teams combine Python and JavaScript services without manually designing APIs or serialization formats. Developers can use each language’s native calling conventions while the runtime handles translation, proxies, and communication behind the scenes.

Read original(opens in new tab)

PythonTypeScriptJavaScriptCloudflare Workers+4

toss·Aug 3, 2026·4 min readCurated summary

How DS and MLE Work Together

The post explains how Toss Bank improved collaboration between Data Scientists (DS) and ML Engineers (MLE) by progressively formalizing their responsibilities. What began as manually transferring notebooks evolved into standardized Python files and finally into installable model packages built around explicit interfaces. The result was faster deployments, consistent observability, and clearer ownership, while AI-generated code introduced a new need to standardize coding style as well. ## Problems with Notebook-Based Handoffs Initially, DS built models and inference code in Jupyter notebooks, then handed them to MLE. - MLE had to recreate the serving code from scratch. - Dependencies, configuration files, and source code were often missing or difficult to reproduce. - Preprocessing logic could be interpreted differently by DS and MLE. - “It works in the notebook” did not guarantee that it would work in production. - As the number of models increased, communication and rework grew rapidly. This approach separated people, not code, so the division of responsibility remained unclear. ## Phase 1: Separating Logic into `.py` Files The team next moved the collaboration boundary from people to files. - DS kept notebooks for experimentation and training. - Core inference logic was extracted into `.py` files. - MLE reviewed these files and validated them through CI. - DS’s intended model behavior was preserved more reliably. - Communication costs decreased. However, the files lacked a standardized structure. - Models used inconsistent function names such as `predict()`, `run()`, and `inference()`. - Code still required modifications when moved into the serving environment. - Global configuration changes in one model could affect other models sharing the same process. - Logging, metrics, and error handling could not be applied consistently across models. ## Phase 2: Defining an Interface Contract The team ultimately standardized the boundary through the `commons-ml-model` package. - A base abstraction defines a common model structure. - DS implements three methods: - `pre_process` - `inference` - `post_process` - The base class handles shared concerns such as: - Logging - Metrics - Tracing - Timing and request tracking - DS packages the implementation as a reusable library. - MLE installs the package with `pip install` and deploys it without rewriting the model. This turns the division of work into a code-level contract. DS focuses on model behavior, while MLE owns serving infrastructure and operational concerns. Updating the base abstraction can also add observability features to every model at once. ## Monorepo Collaboration The team manages the abstraction package and individual model packages in a single monorepo using `uv` workspaces. - Changes to the abstraction and affected models can be reviewed in one pull request. - DS and MLE review the same code in the same repository. - CI, release, and versioning policies are centralized. - Switching from Poetry to `uv` improved build speed by three to five times. The tradeoff is that changes to shared packages can affect many models, and the repository becomes heavier as more packages accumulate. ## Standardizing AI-Generated Code AI-assisted development created a separate collaboration problem: consistent structure did not guarantee consistent coding style. The team introduced `pfmls-stylepack` to encode team conventions for AI tools. - Naming conventions are standardized. - Exception-handling patterns are prescribed. - Rules determine when to use enums instead of hard-coded strings. - Hooks apply conventions while code is being generated. - AI-generated code can explain when a particular rule influenced its implementation. The team therefore distinguishes between: - **Structural consistency:** interfaces define what each role implements. - **Style consistency:** shared rules define how code should be written. Both are necessary for smooth reviews. ## Lessons from the Evolution - The hardest decision is choosing the right collaboration boundary: excessive structure limits flexibility, while insufficient structure recreates inconsistency. - Documentation and early DS–MLE pairing reduce the learning curve for the package-based workflow. - Shared libraries are a double-edged sword: one change can cause broad impact, but one fix can also benefit every model. - In the age of AI-generated code, teams must standardize not only responsibilities and interfaces but also implementation style. The practical recommendation is to make collaboration contracts executable: define stable interfaces, package model code for reuse, centralize shared serving behavior, and enforce coding conventions automatically.

Read original(opens in new tab)

PythonMachine LearningCI/CDAPI Design+4

gitlab·Jul 16, 2026·3 min readCurated summary

When a version bump breaks your build, GitLab fixes it

GitLab’s Dependency Scanning Auto-Remediation aims to reduce security backlogs by automatically upgrading vulnerable dependencies and repairing code when those upgrades break builds. Its AI agent analyzes pipeline errors, changelogs, and code usage, then commits fixes within the same merge request. All changes remain subject to existing reviews, approval gates, and audit controls. ## Why Dependency Backlogs Grow - Transitive dependencies account for a large share of vulnerabilities; one 2025 Maven study found vulnerabilities in about 63% of latest releases through transitive dependencies, compared with 31% through direct dependencies. - Dependency remediation competes with feature work, causing high-severity issues to remain unresolved beyond PCI-DSS and FedRAMP’s 30-day expectations. - Approximately one in eight dependency updates introduces a breaking change, and even “backward-compatible” updates can break builds. - AI-assisted exploit development is also speeding up vulnerability disclosure and weaponization. ## Automated Dependency Upgrades - When SBOM-based dependency scanning identifies a vulnerable package with an available fix, GitLab automatically opens a merge request. - The upgrade targets the nearest fixed version. - If no eligible fix exists, the vulnerability remains in the report until a safe upgrade becomes available. - Each merge request is attributed to a dedicated service account for traceability. - Developers can also start remediation manually for individual findings. ## AI-Powered Breaking-Change Resolution - If the dependency upgrade causes a pipeline failure, GitLab Duo Agent Platform investigates the failure. - It considers: - Pipeline error messages - The dependency’s changelog - How the project uses the dependency - The agent commits necessary application-code changes to the same merge request. - If it cannot restore a passing pipeline, it stops and documents its findings for developers. - Supported ecosystems include Bundler, Maven, Gradle, and major Python and JavaScript/TypeScript package managers; Rust and Go support is planned. ## Safeguards and Governance - Auto-remediation never merges changes automatically. - Merge requests explain the vulnerability, target version, and AI-generated code changes. - Cooldown periods prevent repeated remediation activity from overwhelming projects. - Closed merge requests are not recreated unless a newer fix is available. - Teams can select vulnerability severities and limit upgrades to patch, minor, or major versions. - Remediation runs through the organization’s existing pipelines, access controls, approval gates, and audit trails. - Configuration can be managed at the project or group level through API-based profiles during the beta. ## Availability and Pricing - Dependency Scanning Auto-Remediation is in public beta on GitLab.com, with rollout planned for Self-Managed and Dedicated installations. - Automated version bumping is included with GitLab Ultimate. - Agentic breaking-change resolution is available through a GitLab Duo Agent Platform trial or included GitLab Credits for eligible Ultimate subscribers. GitLab recommends using the feature to turn vulnerable dependencies into reviewable, pipeline-validated merge requests, reducing manual remediation effort without sacrificing developer approval or compliance oversight.

Read original(opens in new tab)

PythonAICI/CDGitlab+4

meta·Jun 30, 2026·2 min readCurated summary

10 Years of Meta’s Commitment to Python

Meta marks its 10th consecutive year sponsoring the Python Software Foundation (PSF), emphasizing that Python is central to its infrastructure, products, and AI work. The company views sponsorship as both a responsibility to the open-source community and a strategic investment in the long-term health, security, and innovation of the technology it relies on. ## Python’s Role at Meta - Python is Meta’s most widely used programming language. - It supports infrastructure for products including Instagram and Threads, as well as AI research and data-driven initiatives. - Meta engineers contribute directly to Python’s development, including core maintenance and Python Enhancement Proposals. - Meta’s open-source contributions include: - PyTorch, originally developed at Meta before becoming an independent foundation. - Pyrefly, a fast Python type checker and language server. - Meta expects Python to remain important as it expands AI capabilities and scales its infrastructure. ## Why Meta Supports the PSF - Open-source adoption creates a shared responsibility to maintain a healthy, secure, and sustainable ecosystem. - PSF funding supports the Developer-in-Residence program, enabling full-time developers to work on Python improvements that might otherwise be neglected or left to volunteers. - Sponsorship helps strengthen PyPI, including critical security improvements that protect package distribution and consumption. - Funding also supports education and community development through: - PyCon US workshops, summits, and discounted or free passes. - Fundraising and support for groups such as PyLadies. - Meta considers these efforts an investment in the tools, infrastructure, and people behind its own technology stack. ## Ways to Support the Python Software Foundation - Individuals can make one-time donations or become PSF members. - Membership may include voting rights and can be supported through financial contributions or volunteer time. - Organizations can become annual sponsors at different contribution levels. - Sponsorship offers public recognition, community engagement opportunities, event participation, and—in higher tiers—greater visibility and invitations to special initiatives. Meta concludes by thanking Python’s maintainers, contributors, educators, and advocates, while encouraging other individuals and organizations to help sustain the language through PSF donations, membership, or sponsorship.

Read original(opens in new tab)

PythonAIMachine LearningOpen Source+3

discord·Jun 30, 2026·2 min readCurated summary

Cost Attribution in Discord’s API

Discord’s API runs from a shared Python codebase with more than 1,700 endpoints and 700 background tasks across hundreds of Kubernetes deployments. While existing observability tracks performance and reliability, Discord lacked a way to understand hosting costs by product feature or endpoint. Because deployments share code and workers handle multiple features concurrently, the solution was to extend application profiling to allocate deployment costs according to the time spent serving each feature. ## A Large, Continuously Deployed API - Discord operates a unified Python codebase containing: - Over 1,700 API endpoints - Around 700 background tasks - Engineers deploy changes daily to several hundred Kubernetes deployments. - Phased rollouts and instrumentation help monitor: - Latency - Throughput - Error rates - These metrics make it possible to detect regressions affecting users or infrastructure. ## The Missing Cost Dimension - Discord wanted to determine how hosting costs were distributed across product features. - Example questions included: - How much does it cost to send and receive messages? - What does it cost to start a stream or send a Nitro gift? - How do feature costs change over time? - Did a recent code change materially affect a team’s hosting spend? - The goal was to measure costs at both: - Individual endpoint level - Broader feature level, such as chat ## Why Kubernetes Deployment Costs Were Insufficient - Cloud providers can generally report costs by Kubernetes deployment. - However, Discord’s deployments do not map cleanly to product features: - The same codebase runs across all deployments. - Each deployment handles a particular subset of HTTP traffic or background tasks. - Splitting deployments further would make the system impractical to operate. - Discord therefore needed cost attribution without changing its deployment topology. ## Allocating Costs Through Profiling - API worker processes handle multiple tasks concurrently. - A single worker may simultaneously perform work for many different features. - Existing traffic isolation was not detailed enough for feature-level cost analysis. - Discord’s approach was to allocate a deployment’s cost based on the amount of time spent executing code associated with each feature. - By extending its application profiling tools, Discord could track this execution time and use it to estimate feature and endpoint hosting costs. In practice, the profiling-based approach provides a way to analyze infrastructure spending within shared deployments, without requiring separate services or Kubernetes environments for every product feature.

Read original(opens in new tab)

PythonKubernetesObservabilityAPI Design+2

aws·Jun 22, 2026·3 min readCurated summary

Run isolated sandboxes with full lifecycle control: AWS Lambda introduces MicroVMs | Amazon Web Services

AWS Lambda MicroVMs provide isolated, stateful execution environments for running untrusted user- or AI-generated code without managing virtual machine infrastructure. Built on Firecracker, they combine VM-level isolation, near-instant startup and resume, and persistent memory and disk state. The post concludes that MicroVMs fill the gap between slow, isolated VMs, less-secure containers, and stateless event-driven Lambda functions. ## The Need for Isolated, Stateful Execution - AI coding assistants, online development environments, analytics tools, vulnerability scanners, and game servers increasingly need a dedicated environment for each user or session. - Traditional options involve tradeoffs: - VMs provide strong isolation but often take minutes to start. - Containers launch quickly but share a kernel and require extensive hardening for untrusted workloads. - Standard serverless functions are designed for short, request-response workloads rather than long-running interactive sessions. - Building custom virtualization infrastructure requires significant security, operations, and virtualization expertise. ## What Lambda MicroVMs Provide - Each user or session receives its own Firecracker-powered MicroVM. - MicroVMs offer: - Dedicated VM-level isolation with no shared kernel between users. - Rapid launch and resume from a pre-initialized snapshot. - Persistent memory, disk state, and running processes during a session. - Automatic suspension during inactivity to reduce idle costs. - Automatic resume when new traffic arrives. - Firecracker already powers AWS Lambda at large scale, providing an established virtualization foundation. ## Creating a MicroVM Image - The example packages a Flask application and Dockerfile into a ZIP archive and uploads it to Amazon S3. - The Dockerfile uses: ```dockerfile FROM public.ecr.aws/lambda/microvms:al2023-minimal ``` - It installs Python and dependencies, copies the Flask application, and starts it with Gunicorn on port 5000. - An image is created with the `aws lambda-microvms create-microvm-image` command, specifying: - The S3 code artifact - An image name - An AWS-provided base image ARN - An IAM build role - Lambda builds the image, initializes the application, and captures its memory and disk state in a Firecracker snapshot. - Build logs are available in CloudWatch under `/aws/lambda/microvms/<image-name>`. ## Launching and Managing a MicroVM - A MicroVM is launched from the image ARN with `run-microvm`. - The example configures an idle policy that: - Suspends the MicroVM after 15 minutes of inactivity. - Keeps it suspended for up to 5 minutes. - Automatically resumes it when traffic returns. - Lambda assigns a unique MicroVM ID and provides a dedicated HTTPS endpoint. - No separate networking setup is required. - The application is already running when the MicroVM becomes available because it resumes from the image snapshot. ## Request Handling and State Preservation - Clients authenticate requests using a short-lived token in the `X-aws-proxy-auth` header. - The Flask API responds immediately after launch. - When the MicroVM becomes idle, Lambda snapshots and stores its memory and disk state. - A later request resumes the environment with the application state intact, making suspension effectively invisible to the client. ## Underlying Execution Model - Lambda MicroVMs use an image-then-launch workflow: - Build and initialize an environment once. - Snapshot the initialized state. - Launch future MicroVMs by resuming that snapshot. - This avoids repeating operating-system and application startup work. - The combination of Firecracker isolation, snapshot-based startup, and suspend/resume lifecycle control makes MicroVMs suitable for secure, interactive, multi-tenant workloads. For applications that must safely execute untrusted code while preserving session state and responsive startup times, Lambda MicroVMs offer a managed alternative to building custom VM infrastructure.

Read original(opens in new tab)

PythonDocker & ContainersAmazon S3Flask+3

line·Jun 22, 2026·4 min readCurated summary

Unifying Analysis Through the Power of Analytics Agents: Work Innovation and Role Transformation in the Generative AI Era at a Professional Organization

PJ One Piece is LY Corporation’s initiative to connect business questions, data analysis, insight generation, and next-action planning through generative AI. Its analysis agent reduced typical turnaround times from about two weeks to roughly 10 minutes, enabling hundreds of analyses each month and adoption by more than half of an early-adopter business unit. The project treats AI not as a chat interface, but as an analysis platform that connects data, knowledge, people, and organizational processes. ## Three Disconnects Behind the Project - **Business and data:** Even with a data warehouse and BI tools, business users still needed to understand SQL, tables, column definitions, KPI rules, and result interpretation. - **Within the analysis process:** Task definition, analysis design, execution, review, and action planning were often handled by different people or tools, causing context loss, rework, delays, and inconsistent quality. - **Across domains:** Useful analysis patterns and domain knowledge remained isolated because services used different KPIs, table structures, business assumptions, and review criteria. ## The Analysis Agent as a Connector - Users ask questions in natural language without needing to know SQL or database structures. - The agent: - Clarifies the business objective and missing assumptions. - Finds relevant data and creates an analysis plan. - Executes queries and specialized analyses. - Interprets results and produces visualizations or reports. - Suggests further analysis and possible next actions. - The platform consists of: - A user-facing application. - An LLM-based agent for reasoning and tool use. - Tools for SQL, Python, document search, and visualization. - A knowledge base containing domain information, skills, and table metadata. - Logging, feedback, monitoring, and evaluation systems. - Domain knowledge is added through a plugin-like structure, while logs and feedback continuously improve the system. ## Turning Business Questions into Analysis Requirements - Natural-language questions often leave important assumptions unspecified, such as: - Target population or campaign definition. - Analysis period and comparison group. - KPI definitions. - Aggregation level. - Exclusion conditions. - Rather than requiring users to write detailed prompts, the agent uses domain knowledge to determine what can be inferred and asks only about unresolved points. - Knowledge bases document service context, KPI definitions, aggregation cautions, policy information, and review requirements. - Table metadata explains available tables, columns, appropriate use cases, samples, partition requirements, and usage restrictions. ## Reaching Data Safely and Reliably - Table metadata is revealed progressively: - The agent first narrows down relevant tables. - It then retrieves detailed definitions and usage rules only for those tables. - Analysis-oriented wide tables or logical views combine transaction data with commonly needed attributes, reducing complicated joins and SQL-generation errors. - SQL is checked before and after execution to enforce: - `SELECT`-only access. - Approved tables and usage rules. - Required partition conditions. - Restrictions on sensitive or personal data. - Result-size limits. - These guardrails allow the agent to perform analysis flexibly without exposing data or infrastructure to unnecessary risks. ## Preserving Context Across the Analysis Process - PJ One Piece uses a supervisor-style multi-agent architecture. - A main agent maintains: - The user’s request and business objective. - The current analysis plan. - Findings and constraints discovered so far. - Remaining questions and decision points. - Specialized sub-agents handle tasks such as statistical testing, time-series analysis, clustering, and independent review. - This separates complex or specialized work from the main context while preserving overall continuity. - Progress updates expose discoveries, design decisions, data limitations, and constraints so users can adjust direction during longer analyses. ## Building Reusable Organizational Capability - Logs record agent actions, assumption checks, analysis designs, generated SQL, errors, and outputs. - User and analyst feedback helps identify whether improvements are needed in prompts, tools, data, or reusable skills. - Repeated workflows are formalized as skills, including: - General-purpose methods such as time-series and clustering analysis. - Domain-specific workflows such as monthly reporting or policy monitoring. - Skills document required assumptions, comparison axes, cautions, and interpretation methods. - Over time, isolated domain knowledge becomes reusable organizational analysis capability. ## Business Impact - In early deployment, the platform expanded data use beyond data scientists to product owners and frontline employees. - More than half of the participating business unit’s members use it. - Analysis turnaround fell from an average of approximately two weeks to about 10 minutes. - The platform now supports hundreds of analyses per month and serves as a daily starting point for business questions. PJ One Piece’s main recommendation is to design AI analysis as an end-to-end operating platform—not merely an automated SQL or chatbot tool. Combining structured domain knowledge, safe data access, contextual multi-agent workflows, reusable skills, and continuous evaluation can make analysis faster while steadily improving its quality and organizational reach.

Read original(opens in new tab)

PythonLarge Language ModelsAI AgentsGenerative AI+4

aws·Jun 9, 2026·3 min readCurated summary

Anthropic Claude Fable 5 on AWS: Mythos-class capabilities with built-in safeguards now available | Amazon Web Services

Claude Fable 5 is now available through Amazon Bedrock and Claude Platform on AWS, offering Mythos-level performance with safeguards for broader access. Anthropic highlights its ability to perform long-running tasks, analyze complex visual documents, and verify or improve its own work. Access requires specific data-sharing consent, and higher-risk requests may be routed to Claude Opus 4.8. ## Capabilities and Safeguards - Supports extended, asynchronous coding and knowledge-work tasks with minimal intervention. - Interprets diagrams, charts, tables, files, and PDFs for research, finance, legal, analytics, architecture, gaming, and software development. - Uses vision to compare implemented designs with intended goals. - Can update skills, create evaluation harnesses, and perform proactive self-verification. - Cybersecurity, biology, chemistry, and health prompts with elevated misuse risk may be handled by Opus 4.8 instead. - The unrestricted Claude Mythos 5 is limited to a small group of vetted customers. ## Accessing Fable 5 on Amazon Bedrock - Available through: - Anthropic’s Messages API using `bedrock-mantle` or `bedrock-runtime`. - AWS Invoke and Converse APIs through `bedrock-runtime`. - The Amazon Bedrock console Playground. - Model access is being expanded gradually across AWS accounts; customers can contact AWS Support for expedited access. ## Required Data Sharing - Users must opt into data sharing through the Data Retention API by setting `provider_data_share`. - No console interface is available for this setting at launch. - Anthropic requires: - 30-day retention of inputs and outputs. - Human review. - Data retention enables abuse detection across multiple interactions rather than isolated requests. - Example endpoints are provided for both `bedrock-mantle` and `bedrock-runtime`. ## SDK and API Usage - Install the Anthropic Python SDK with `pip install anthropic`. - The Messages API can be called through the Bedrock Mantle endpoint using model ID `anthropic.claude-fable-5`. - Boto3’s Converse API supports unified multi-model access through model ID `global.anthropic.claude-fable-5`. - Users can configure token limits and submit tasks such as designing a multi-region AWS architecture supporting 100,000 requests per second. ## Pricing and Routing - Requests routed to Opus 4.8 because of harmful content are charged at Opus rates. - If a conversation is blocked mid-request, initial tokens are charged at Fable rates and later tokens at Opus rates. - Pricing details are available on the Amazon Bedrock pricing page. Claude Fable 5 is best suited to ambitious, long-running workloads that benefit from advanced reasoning and document or visual understanding. Before using it, organizations should confirm account access, configure the required data-sharing settings, and evaluate whether the 30-day retention and human-review requirements fit their compliance policies.

Read original(opens in new tab)

PythonGenerative AIAmazon BedrockAws Cli+4

gitlab·Jun 9, 2026·3 min readCurated summary

Shai-Hulud copycat campaign targets Python developers through PyPI typosquatting

GitLab researchers uncovered a coordinated PyPI supply-chain campaign distributing a copy of the Shai-Hulud worm. Five packages—four typosquats and one compromised legitimate project—execute malware during Python startup, steal credentials from CI/CD and cloud environments, and propagate through developers’ repositories and package registries. The campaign demonstrates that Python packages can be weaponized without imports or explicit function calls. ## Malicious PyPI Packages - All packages were published by the `elitexp` account: - `rlask` and `tlask`, typosquats of Flask - `rsquests`, a typosquat of Requests - `nhmpy`, a typosquat of NumPy - `mflux-streamlit`, a legitimate project later weaponized in versions `0.0.3` and `0.0.4` - The attacker first uploaded clean probe versions matching current upstream version numbers, then replaced them with payload-bearing releases. - The activity followed the public release of Shai-Hulud’s source code, suggesting an independent copycat operation targeting Python users. ## Python Startup-Based Infection - The malware uses Python `.pth` files, which Python processes automatically at startup. - The dropper: - Checks for a `.bun_ran` marker in the temporary directory. - Downloads the Bun JavaScript runtime from GitHub. - Executes a roughly 5 MB obfuscated JavaScript payload. - Early `rlask` versions also included `sitecustomize.py`, which searched `sys.path` for and executed a hidden `_index.js` file. - This approach requires no explicit package import or function invocation. ## Payload Obfuscation - The JavaScript is protected by multiple layers: - Package-specific ROT-N encoding - AES-128-GCM encryption - Variable-name mangling using `_0x` identifiers - Researchers identified: - A small encrypted Bun downloader - A 772 KB Shai-Hulud credential stealer - Approximately 2,538 hardcoded strings ## Credential Theft The worm targets credentials and secrets from: - GitHub Actions tokens, repository secrets, OIDC tokens, artifacts, and runner memory - AWS IAM credentials, instance metadata, Secrets Manager, SSM, and STS tokens - Azure managed identities, Key Vault, and Microsoft Graph tokens - GCP service-account keys and application credentials - HashiCorp Vault tokens and Kubernetes authentication - npm, JFrog, PyPI, and RubyGems publishing credentials - SSH private keys and Kubernetes service-account tokens - Sigstore credentials and Fulcio signing certificates - MongoDB, MySQL, PostgreSQL, and Redis connection strings ## Self-Propagation Using stolen credentials, the worm can: - Add `.github/setup.js` and workflow files to repositories so it runs in other CI pipelines. - Insert `.github/copilot-instructions.md` to influence AI coding assistants. - Publish poisoned packages to PyPI, npm, and RubyGems. - Attempt privilege escalation on self-hosted runners through `sudoers` modifications. - Detect StepSecurity’s harden-runner and alter its behavior. ## Attacker Infrastructure and Weaponized Project - The PyPI account was created in 2024 and was associated with the legitimate `mflux-streamlit` project. - Package uploads used `Bun/1.3.14`, matching the runtime downloaded by the malware. - Unlike a pure typosquatting campaign, the compromise of a real project could affect existing users through normal dependency updates. Developers should audit environments for the affected packages, review CI/CD and cloud credentials, rotate exposed secrets, and enforce dependency pinning and package provenance checks. CI runners and publishing tokens should be treated as potentially compromised if any affected version was installed.

Read original(opens in new tab)

PythonKubernetesCI/CDSupply Chain Security+2

toss·Jun 8, 2026·4 min readCurated summary

Rubric Design and System Implementation for Skill Quality Management

Toss’s AI DX Team created a 30-item rubric to improve the quality of internal Skills used by coding agents. The central conclusion is that deterministic defects should be checked with rules, while semantic questions—especially whether a Skill will be triggered—should be evaluated by an LLM. This separation improves accuracy, cost efficiency, and developer feedback. ## Why Skill Evaluation Is Difficult Skills are artifacts that are both invoked and read by LLMs, so they lack the compiler and test-based validation available for code. - Defects can accumulate silently: - A Skill may never be invoked. - It may be invoked but have little practical effect. - Two especially common problems are: - **Trigger failure:** Trigger conditions are placed in the Skill body instead of its description. Agents inspect the description when deciding whether to invoke a Skill; the body is read only afterward. - **Format failure:** Invalid naming conventions, mismatched folder names, or malformed metadata can prevent the agent from recognizing the Skill at all. ## Rules for Deterministic and Semantic Checks The rubric explicitly separates the 30 checks into: - **17 rule-based checks** - Use regular expressions, counts, and AST parsing. - Handle objective issues consistently and cheaply. - **13 model-based checks** - Use an LLM for meaning-dependent judgments. - Evaluate questions such as whether a description adequately communicates when the Skill should be used. Mixing the two approaches causes problems: - LLMs may overlook clear format violations. - Regular expressions produce false positives when trying to understand varied natural-language intent. - Rule checks can run on every pull request at nearly no cost. - Model checks run only after structural blockers have passed, reducing LLM expenses. ## Rubric Structure and Severity The rubric contains six sections and 30 evaluation items. - Each item is classified as: - **BLOCKER** - **MAJOR** - **MINOR** - Results are summarized using grades from **S to F**. - Any single BLOCKER automatically produces an **F**. - The grade is primarily a compact signal for authors; merge eligibility is simplified to whether the result is F or not-F. ## Validity: Does the Skill Need to Exist? The validity section contains three MAJOR checks. - It asks whether the Skill: - Has a legitimate reason to exist. - Provides recurring or reusable value. - Offers something more useful than simply asking the coding agent to perform the task directly. - This section is intended to identify Skills that should not have been created in the first place. ## Structure: Catching Format Errors The structure section has eight checks, including five BLOCKER-level checks. The rule-based implementation verifies items such as: - Presence and parseability of YAML frontmatter. - `name` following lowercase kebab-case. - Consistency between the Skill’s `name` and its folder name. - Description length between 1 and 1,024 characters. - Absence of XML tags in the body. The checks collect all failures and return them together so authors can fix multiple problems from a single pull-request comment. Only an unrecoverable frontmatter parsing failure causes an immediate return. ## Trigger Design: Making Skills Discoverable The trigger section contains six checks, including one BLOCKER. - A description must communicate both: - **WHAT** the Skill does. - **WHEN** it should be used. - A detailed “when to use” section in the body is insufficient because the agent cannot see the body during invocation selection. - The team initially tried regular expressions to detect trigger signals such as: - “when” - “use when” - Korean expressions meaning “when using” or “at the time of.” - This produced failures because trigger intent can be expressed through emojis, indirect wording, and many other forms that keyword lists cannot cover. - The final approach assigns the semantic question—whether the description covers the body’s trigger conditions—to an LLM. The resulting design favors simple, repeatable rule checks for formal correctness and model-based evaluation only where natural-language meaning is unavoidable.

Read original(opens in new tab)

PythonLarge Language ModelsYamlCoding Agents+3

google·Jun 3, 2026·3 min readCurated summary

The next chapter in flood resilience: Open sourcing Google’s hydrology framework

Google Research has open-sourced the hydrology framework behind its Flood Hub river forecasts. The Python/PyTorch package lets researchers and national forecasting agencies train AI models with global and local data while retaining control over their information. Google argues that open access, local expertise, and interoperable tools can make advanced flood warnings more accurate, affordable, and widely deployable. ## The Open-Source Hydrology Framework - The framework is available on GitHub under an Apache 2.0 license. - It provides model architectures, training pipelines, documentation, and tutorials. - Users can train models with climate, soil, topography, land-cover, and weather data. - Historical river observations come from the open Caravan dataset, which agencies can extend with local measurements. - The package is built with PyTorch and is intended for both researchers and operational forecasters. ## Model Versions and Improvements - The release includes: - The original model used in Google’s 2024 benchmarking study. - An upgraded v2 model currently used for real-time global forecasts in Flood Hub. - The v2 model uses a multi-input ME-LSTM architecture. - Separate networks embed different meteorological products before combining them in an LSTM. - Inputs include GraphCast, ECMWF forecasts, NASA IMERG satellite rainfall estimates, and NOAA CPC precipitation data. - Benchmarking showed the newer model extends the reliable forecast horizon by: - Six days in gauged river basins. - One day in ungauged basins. ## Local Data and Operational Forecasting - Agencies can fine-tune models for specific watersheds using local observations and expert knowledge. - The approach supports the integration of Indigenous and Local Knowledge, which the World Meteorological Organization says is still rarely incorporated systematically. - Models are designed to be relatively inexpensive and easier to train than traditional conceptual hydrological systems. - Local organizations can preserve control over their data while adapting the models to regional conditions. ## Partnership with the Czech Hydrometeorological Institute - Google worked with CHMI to validate the model against locally calibrated traditional forecasting models. - CHMI created an adapter connecting the framework to Delft-FEWS, a widely used operational forecasting platform. - This integration demonstrates how machine-learning forecasts can fit into existing workflows used by government agencies, NGOs, and private organizations. - The partnership provides a practical model for other national hydrological services. ## Broader Flood-Resilience Goals - Open-source distribution could help resource-constrained regions access advanced forecasting without expensive infrastructure. - The framework is intended to support capacity building for early-warning systems worldwide. - Google presents the release as a way to let the global hydrology community reproduce, improve, and localize its research. National hydrological agencies and researchers should evaluate the open-source framework using their own watershed data, integrate it with existing forecasting systems, and validate its predictions against established local models before operational deployment.

Read original(opens in new tab)

PythonMachine LearningPytorchFlood Forecasting+3

aws·Jun 1, 2026·3 min readCurated summary

Get started with OpenAI GPT-5.5, GPT-5.4 models, and Codex on Amazon Bedrock | Amazon Web Services

OpenAI GPT-5.5, GPT-5.4, and Codex are now generally available through Amazon Bedrock. GPT-5.5 targets the most demanding coding, reasoning, and agentic workloads, while GPT-5.4 emphasizes price-performance. Customers can access the models through the Responses API and use Codex across CLI, desktop, IDE, and Xcode integrations, with regional processing and token-based pricing. ## Model Access Through Amazon Bedrock - Models are served through Bedrock’s next-generation inference engine and the OpenAI Responses API. - GPT-5.5 is positioned for the hardest workloads; GPT-5.4 offers a balance of capability and cost. - Processing remains within the selected Bedrock Region, supporting data residency requirements. - Pricing is based on token usage, with no seat licenses or per-developer commitments. ## Calling GPT Models Programmatically - The OpenAI Python SDK can be configured with Bedrock’s OpenAI-compatible endpoint: - Install with `pip install -U openai`. - Set `OPENAI_BASE_URL`, `OPENAI_API_KEY`, and `BEDROCK_OPENAI_MODEL_ID`. - Applications can call `client.responses.create()` with: - Developer and user messages - Configurable reasoning effort - Output verbosity controls - The same endpoint can be called directly with `curl`. - The Responses API supports multi-turn state, hosted and function tools, tool orchestration, and background or long-running work. ## Using Codex with Bedrock - Codex is available through the Codex CLI, desktop app, VS Code, JetBrains, and Xcode integrations. - It supports: - A Bedrock API key via `AWS_BEARER_TOKEN_BEDROCK` - The AWS SDK credential chain as a fallback - Configure the model and Region in `~/.codex/config.toml`, for example: - Model: `openai.gpt-5.5` - Provider: `amazon-bedrock` - Region: `us-east-2` - Other supported model IDs include `openai.gpt-5.4`, `openai.gpt-oss-120b`, and `openai.gpt-oss-20b`. - Desktop and VS Code users can place environment variables in `~/.codex/.env`. - Applications must be restarted after configuration changes. ## Latency and Scaling Considerations - Actual latency depends on reasoning effort, response length, tool calls, background execution, Region, quotas, throttling, prompt size, and cache hits. - AWS recommends starting GPT-5.5 with medium reasoning effort. - GPT-5.4 should use an explicitly chosen effort level rather than relying on its default of `none`. - Bedrock’s inference engine is designed to provision capacity dynamically. - During demand spikes, requests may be queued instead of rejected. ## Regional Availability - GPT-5.5 is initially available in the US East (Ohio) Region. - GPT-5.4 is available in US East (Ohio) and US West (Oregon). - Additional Regions may be added over time. Teams needing advanced coding and reasoning capabilities can now use OpenAI models and Codex through Bedrock while retaining AWS authentication, regional processing, and usage-based pricing. Evaluate reasoning effort, latency, quotas, and regional availability before moving workloads into production.

Read original(opens in new tab)

PythonAmazon BedrockAws SdkCurl+4

gitlab·May 21, 2026·4 min readCurated summary

GitLab 19.0 | GitLab Docs

GitLab 19.0, released May 21, 2026, expands AI-assisted development, work-item customization, secrets management, and dependency security. Major changes include group-level Duo review instructions, configurable work-item types, open beta access to GitLab Secrets Manager, and generally available SBOM-based dependency scanning. GitLab also introduces usage-based billing for Duo Core and adds new agent, search, model, and workflow capabilities. ## Customization and Project Management ### Group-level custom review instructions for GitLab Duo - Premium and Ultimate feature for GitLab.com, Self-Managed, and Dedicated. - Groups and subgroups can share review guidance through: ```text .gitlab/duo/mr-review-instructions.yaml ``` - A project in the group serves as the template. - Group instructions are combined with project-specific instructions. - Supported by both Code Review Flow and GitLab Duo Code Review. ### Configurable work item types - Projects can define custom types such as User Story, Bug, or Maintenance instead of using only Issues and Tasks. - Each type has its own name and icon. - Types support custom fields, status lifecycles, saved views, and issue boards. - Configuration at the top-level group or organization cascades to projects. - Administrators can enable or disable types globally or allow project-level control. - Disabling a type does not affect existing work items. ## Security and Dependency Management ### GitLab Secrets Manager enters open beta - Available to Premium and Ultimate customers on GitLab.com and GitLab Self-Managed. - Project and group Owners can store and reference CI/CD secrets in GitLab. - Secrets are scoped to projects or groups and available only to jobs that explicitly request them. - The feature remains subject to beta support policies and may not be production-ready. ### SBOM-based dependency scanning becomes generally available - Available for Ultimate customers across GitLab offerings. - Maven, Gradle, and Python projects receive visibility into transitive dependencies and their vulnerabilities. - Automatic dependency resolution runs when no lockfile or dependency graph is available. - If resolution is unavailable, manifest scanning examines direct dependencies in files such as: - `pom.xml` - `requirements.txt` - `build.gradle` - `build.gradle.kts` - Manifest scanning is enabled by default, while full transitive coverage requires dependency resolution, a lockfile, or a manually supplied dependency graph. ## GitLab Duo and Agentic Development ### Duo Developer enhancements - GitLab Duo Developer can be triggered by: - Assigning it to an issue - Selecting **Generate MR** - Mentioning it with `@mention` in an issue or merge request discussion - It can turn feedback, to-do items, and design questions into code changes, follow-up merge requests, or research summaries. - With `AGENTS.md` and `agent-config.yml`, it can run tests and checks before committing. - Administrators can enable mention and assignment triggers for eligible projects. ### Duo Core adopts usage-based billing - Code Suggestions in the Web IDE and desktop IDEs now consume GitLab Credits. - Duo Chat becomes agentic for Duo Core users and runs on the GitLab Duo Agent Platform. - Administrators must enable the Agent Platform for the instance or top-level group to use Chat in GitLab or desktop IDEs. ### New agent and search capabilities - Exact code search supports repository filtering with the `repo:` syntax: ```text def authenticate repo:my-group/my-project ``` - Flows and external agents can trigger when a draft merge request is marked ready for review. - The merge request ready trigger is controlled by the `merge_request_ready_flow_trigger` feature flag and is disabled by default. - Claude Opus 4.7 is available in the Duo Agent Platform for complex, multistep tasks involving code review, CI/CD, and vulnerability resolution. - GitLab Duo Agent Platform Self-Hosted adds compatibility with Gemini models and supports multiple flows, including Code Review Flow and SAST vulnerability workflows. GitLab 19.0 is particularly significant for teams adopting AI agents and centralized development governance. Organizations should review Duo’s new billing model, test Secrets Manager carefully during its beta period, and enable dependency resolution to obtain comprehensive vulnerability coverage.

Read original(opens in new tab)

PythonCI/CDGitlabGitlab Duo+4

line·May 15, 2026·3 min readCurated summary

ODW #6: The Pros and Cons of MCP and Agent Skills from a Git Automation Perspective

The post presents agent skills as a simpler, more practical alternative to building MCP servers for many AI-agent workflows. It demonstrates how to use Anthropic’s `skill-creator` to build a Git release automation skill that analyzes commits, updates a changelog, bumps versions, commits, tags, and pushes releases. The author emphasizes that precise requirements and explicit constraints are essential for preventing unintended agent behavior. ## Why Agent Skills Are Practical - Agent skills can simplify both implementation and architecture compared with custom MCP servers. - Although online examples explain the concept, the post focuses on a practical, work-oriented use case. - The tutorial assumes familiarity with the basic concept of skills and concentrates on building and applying one. ## Git Smart Release Automation The example skill automates releases for a Git project in the current working directory. - Reads the Git history after the most recent tag. - Summarizes changes and adds them to the top of `CHANGELOG.md`. - Creates `CHANGELOG.md` if it does not exist. - Updates the version in `pyproject.toml`. - Commits the changelog and version changes. - Creates a corresponding Git tag. - Operates based on the terminal’s current `pwd`. ## Using `skill-creator` - Anthropic’s official `skill-creator` skill is used to generate the new automation skill. - The user provides a detailed requirements specification rather than implementing everything manually. - Explicit workflow steps and constraints help keep the agent focused on the correct directory and avoid unnecessary complexity. - The development process is demonstrated with Claude Code. ## Clarifying Requirements Before generating the skill, the agent asks questions to resolve ambiguous behavior. - Support patch, minor, and major version bumps. - Use `v0.1.0` for the first release when no prior tag exists. - Follow a structured changelog format. - Push both commits and tags to the remote repository. - Abort with an explanation if the working directory contains uncommitted changes. ## Generated Skill Structure The completed skill contains: - `SKILL.md` — instructions and metadata for the agent. - `scripts/smart_release.py` — a local Python script that performs Git operations and file modifications. - `evals/evals.json` — evaluation cases for testing the skill. The skill also includes: - Keep a Changelog-style updates. - Dirty working-directory checks. - Automatic remote pushing. - Commit categorization such as `feat`, `fix`, and `docs`. ## `SKILL.md` and the Python Script - The frontmatter in `SKILL.md` acts as a concise discovery description that helps the agent decide when to load the skill. - The Markdown body provides the detailed execution workflow. - `smart_release.py` handles operations requiring deterministic file and Git manipulation, reducing the need for the language model to process raw data directly. - The post then begins testing the skill with a simple Python calculator project. A practical approach is to define release behavior, edge cases, and safety constraints before asking an agent to generate the skill, while delegating file and Git operations to a local script.

Read original(opens in new tab)

PythonModel Context ProtocolClaude CodeGit+3