githubJul 22, 2026

Copilot vs. raw API access: What are you actually paying for? (opens in new tab)

GitHub Copilot and direct model APIs serve different purposes rather than competing at the same layer. Copilot bundles model access with development workflows—repositories, editors, terminals, issues, pull requests, and organizational controls—while APIs give teams the primitives to build their own systems. The best choice depends on whether you want to own the surrounding infrastructure or use GitHub’s integrated tooling. ## Copilot as Development Tooling - Copilot supports workflows from GitHub Issues through code changes, testing, pull requests, and review. - Its value includes integration with: - Editors and repositories - Terminals and permitted commands - Repository instructions - Pull requests and organizational policies - Paid plans include code completions and Next Edit Suggestions, while more intensive chat and agentic tasks consume AI Credits. - Actual cost depends on context selection, input/output/cached tokens, tool calls, retries, and task complexity. - Organization plans pool credits and provide budgets and usage tracking through the billing dashboard. ## Raw APIs for Systems You Control - Direct API access is suited to product features, internal agent platforms, evaluation systems, and automation pipelines. - Teams control prompts, retrieval, model routing, retries, logging, security, credentials, and billing. - Production agents still require substantial engineering, including: - Selecting relevant repository or document context - Preserving instructions - Handling failed tool calls - Storing traces and audit records - Defining data boundaries and approval points - Agent SDKs can provide orchestration, tools, sessions, and streaming. GitHub’s Copilot SDK exposes the runtime used by Copilot CLI and can run with either a Copilot subscription or a provider key. ## BYOK: Keeping Copilot’s Workflow - Copilot’s public-preview Bring Your Own Key feature lets teams use supported external models in Copilot Chat, CLI, and VS Code. - Supported providers include Anthropic, AWS Bedrock, Google AI Studio, Microsoft Foundry, OpenAI, OpenAI-compatible services, and xAI. - GitHub continues to provide the Copilot harness and integrations, while the customer pays the model provider directly. - BYOK can preserve existing cloud contracts or provider commitments while maintaining a familiar Copilot workflow. - Administrators can control which GitHub-hosted or BYOK models teams may use. - Because BYOK is still in public preview, teams should consult the current documentation before making purchasing or architecture decisions. ## Choosing the Right Layer - Choose raw API access when you need custom integrations, behavior, security controls, auditing, or billing. - Choose Copilot when developers primarily need to work faster within existing repositories, editors, terminals, issues, pull requests, reviews, and security processes. - BYOK is a middle option for teams that want GitHub’s development workflow but prefer to pay for models through an existing provider relationship. The practical decision is not simply about token price. It is about whether your team needs to build and operate the surrounding AI system or wants an integrated development workflow managed through Copilot.

apillmgithub-copilotagentic-workflows+4

cloudflareJul 1, 2026

Announcing the Monetization Gateway: charge for any resource behind Cloudflare via x402 (opens in new tab)

Cloudflare is introducing the Monetization Gateway, which will let customers charge for web pages, datasets, APIs, and MCP tools protected by Cloudflare. It combines payment rules, access control, metering, and payment verification at the edge, initially using stablecoins through the x402 protocol. The goal is to make low-cost, usage-based payments practical for AI agents without requiring sellers to build billing infrastructure or onboard every buyer. ## The Web’s Shift Toward Usage-Based Payments - The traditional web monetized human attention through advertising, subscriptions, and e-commerce. - AI agents consume resources without viewing ads or maintaining subscriptions, creating a need for pricing based on actual usage. - Potential models include: - Charging a few cents per search. - Combining a base fee with usage charges, such as per megabyte uploaded. - Charging only when an outcome succeeds, such as a resolved support escalation. - Agents may generate thousands of requests and micropayments, making per-request, per-token, or outcome-based pricing more appropriate than monthly or per-seat plans. - Existing usage billing has generally required API keys, known customers, extensive accounting systems, and costly payment infrastructure. - Stablecoins such as USDC and Open USD can support sub-cent payments with low fees and settlement times under a second. ## Cloudflare’s Role in Usage-Based Billing - Cloudflare can use its position as a proxy between buyers and sellers to combine payment verification with the request path. - Metering, payment exchange, and settlement can occur away from the customer’s origin. - Customers retain control over: - Pricing. - Access rules. - Revenue. - Sellers will not need to onboard each buyer or build a complete billing system; they can define rules that determine when agents must pay. ## How x402 Payments Work - x402 uses HTTP’s `402 Payment Required` status code to add payments directly to ordinary web requests. - The flow is: - A client requests a protected resource. - The server returns a 402 response containing the price, accepted asset, and payment destination. - The client pays and retries the request with proof of payment. - A facilitator verifies the payment. - The server returns the requested resource. - There are no checkout redirects or separate payment APIs. - Payments settle peer-to-peer directly into the seller’s wallet. - x402 is well suited to machine payments because: - It supports very small transactions. - Buyers do not need an account with the seller. - The payment itself acts as the access credential. - Stablecoins offer fast settlement, low fees, and no chargebacks. ## Monetization Gateway Capabilities - Customers will define payment policies through a dedicated rules API using expressions similar to other Cloudflare rules. - The system will apply to traffic such as tokens, APIs, MCP tool calls, and datasets. - Enforcement will run across Cloudflare’s network in more than 330 cities, allowing payment handshakes to occur near buyers while reducing latency and protecting origins. - Planned functionality includes charging for specific REST methods and routes, such as requiring $0.01 for each `GET` or `POST` request to `/api/premium/*`. - The gateway is also intended to support variable pricing for tasks with different costs. Cloudflare’s approach is to make micropayments a native part of HTTP access, enabling businesses to charge agents directly for the resources they consume without constructing their own payment and accounting systems.

apiai-agentcloudflaremcp+4

tossJun 19, 2026

Going Beyond Expertise (opens in new tab)

Technical Writers (TWs) can contribute far beyond writing documentation: they can lead product teams and build systems that turn knowledge into an organizational asset. Toss’s Knowledge System Team created “todoc,” an internal platform that makes documentation easier to write, centralizes scattered knowledge, and enables AI access. Its broader goal is to make documentation emerge naturally from daily work and remain accurate without constant manual maintenance. ## TWs as Product Owners and Makers - The author leads a product team of developers, designers, and TWs. - Their responsibilities include: - Setting product direction, roadmap, and priorities - Interviewing users and bringing insights to the team - Planning features - Building features directly with AI tools - TW expertise is especially valuable because TWs have deeply considered: - Why documents are difficult to read - What makes documentation effective - How information should be structured for AI consumption ## Why Toss Built Todoc Todoc was launched to address weaknesses in Toss’s existing documentation environment. - Static-site-generated documentation required users to: - Clone a repository - Write Markdown - Submit pull requests - Wait for review - This workflow was familiar to developers but created major barriers for designers, PMs, and other non-developers. - Existing documentation tools accumulated outdated policies, unfinished notes, and unexplained content, creating “documentation debt.” - Knowledge was fragmented across: - Static sites - Documentation tools - Code - Collaboration messengers - Individual employees’ knowledge After its beta launch, Todoc grew to more than 500 documents and 40,000 valid pages, with over 1,000 monthly users. ## Todoc’s Four Core Values ### Easy Documentation for Everyone - Anyone can create or edit documents immediately. - Content can be connected from GitHub, documentation tools, internal messengers, and other sources. - The platform removes the technical and procedural barriers to documentation. ### AI-Ready Knowledge - Well-organized documentation can be used by team bots and other AI tools. - Todoc supports API, CLI, and MCP access. - Teams use it for request bots, product specifications, and other workflows. ### A Single Source of Truth - Todoc consolidates scattered sources into complete, centralized documents. - Users can determine which information is current without searching across multiple systems. - The platform serves as the organization’s SSoT (Single Source of Truth). ### Scalable Infrastructure - Teams no longer need to select, build, or maintain their own documentation infrastructure. - Each team can have its own space on a shared platform. - The model is being expanded to Toss affiliates. ## Automating Documentation Quality and Maintenance Lowering the barrier to writing creates a new challenge: maintaining quality. - TW judgment is being converted into: - AI proofreading - Automated document reviews - Bots that generate initial drafts - Todoc is also designed to create documentation automatically from: - Decisions and discussions in internal messengers - Code changes - Ongoing project conversations - The system aims to update documents without relying on someone remembering to maintain them. - It evaluates whether knowledge is still valid by checking: - Whether policies match implemented code - Whether information is actively used - How recently it was updated ## The Evolution of TW Expertise The role is shifting from writing excellent documents manually to designing systems that consistently produce and maintain excellent documentation. - Experience understanding why documents are hard to read becomes standards for human- and AI-readable content. - Judgments about what makes a good document become criteria for AI review and automated editing. - Expertise in identifying outdated information becomes a system for validating knowledge. - TWs increasingly focus on: - Creating places where knowledge can gather - Defining quality standards - Encoding human judgment into systems - Generating documentation through normal work - Keeping knowledge continuously updated The practical vision is an organization where outdated documents trigger their own notifications, project work leaves behind organized records, and recurring explanations are preserved for future employees. Toss’s Technical Writing Chapter is therefore working to systematize TW expertise and establish documentation governance so teams can document effectively without constant manual intervention.

apiaigithubmcp+4

cloudflareJun 12, 2026

Scaling Security Insights: how we achieved a 10x increase in global scanning capacity (opens in new tab)

Security Insights needed a 10x throughput increase to scan all customers more frequently and detect risks sooner. The existing system was overwhelmed by Kafka backlogs, slow processing, database inefficiencies, and API timeouts. Cloudflare improved capacity by introducing parallel and lane-based processing, optimizing bulk database writes, and addressing regional latency between its API and database. ## Scaling Kafka Processing - Scans are scheduled and published to Apache Kafka. - Go-based checker services consume these messages, inspect accounts, zones, and DNS records, and send findings to an internal API. - Kafka’s partition ordering limits each consumer group to one active consumer per partition. - Slow messages could block all subsequent messages in the same partition. - Adding partitions was avoided because it would increase resource usage for shared Kafka brokers. ## Introducing Parallel Processing - Checkers were changed to consume messages in batches. - Each message in a batch is processed concurrently in its own goroutine. - This increased throughput without requiring additional Kafka partitions. - The trade-offs were higher memory usage and potentially more work to repeat after a process crash. ## Separating Slow and Fast Work - Some scans took seconds or milliseconds, while unusually large accounts or zones could take minutes or hours. - These slow messages caused head-of-line blocking for faster work. - Consumer groups and checkers were split into: - A fast lane for predictable, short-running scans - A slow lane for messages expected to require substantially more time - Fast-lane consumers skipped slow messages, allowing normal scans to continue without delay. ## Optimizing Postgres Writes - The API originally executed one insert/upsert transaction per insight. - A request containing up to 500,000 insights could therefore generate hundreds of thousands of database round trips. - Bulk insertion with `COPY` into a temporary table was tested but caused bloat in Postgres system tables. - The final hybrid approach used: - `UNNEST` for smaller batches - `COPY` for batches above a configured threshold - This delivered millisecond-level performance for small writes and completion within seconds for very large writes. ## Diagnosing API Timeouts - Client-side timeouts increased as scan volume grew. - Checkers sometimes spent 20–90% of their processing time waiting on a single API call. - Throughput initially rose but then deteriorated under heavy load. - The root cause was network latency: - Postgres was hosted in Portland, Oregon. - The API ran active-active in Portland and Amsterdam. - Requests routed to Amsterdam incurred roughly 50 milliseconds of network round-trip latency. - Amsterdam database queries held client connection-pool connections much longer—nearly three seconds on average versus about 10 milliseconds in Portland. - The connection pool became exhausted, causing requests to wait for available connections and creating uneven Kafka lag across partitions. Cloudflare’s results came from improving the full processing pipeline rather than relying on a single infrastructure change. Parallelize message handling, isolate slow workloads, batch database writes, and place latency-sensitive services close to their databases to achieve large throughput gains and more frequent security scanning.

apipostgresqldistributed-systemsmicroservices+4

tossJun 9, 2026

How Do TAMs Solve Problems in Fast-Moving Organizations? (opens in new tab)

TAM CONNECT 2025 brought together Technical Account Managers from Toss and Kakao Pay to compare how they connect technology, business, customers, and internal teams. Although their organizations differ, they face similar challenges: operational complexity, cross-team coordination, recurring incidents, and the need to improve customer experience. The event framed TAMs not as basic support staff, but as technology-driven problem solvers whose role is expanding through automation and AI. ## The Scope of a TAM’s Role - TAMs resolve partner integration issues and advise on API adoption. - They coordinate multiple teams during incidents and improve operational processes. - Their work includes automating recurring problems and influencing product and platform design. - Depending on the situation, a TAM may act like a developer, product manager, or incident leader. - At Toss, their responsibilities span authentication, Face Connect, financial platforms, online and offline payments, and partner APIs. ## Reducing Alert Noise and Preventing Recurring Problems - Toss’s Dayoung Park presented a problem-solving framework that began by redefining which alerts truly require attention. - Excessive notifications can obscure serious incidents, so the team focused on identifying meaningful operational signals. - They structured incident patterns, detected recurring issues automatically, and analyzed the root causes of settlement discrepancies. - The goal was not merely to resolve incidents faster, but to build systems that prevent them from recurring. ## Making Operations Independent of Individual Owners - PayToss’s Gimun Lee discussed reducing dependency on specific people’s knowledge. - Response histories and operational information were shared transparently so anyone could handle an issue. - Their Discord developer community used n8n workflows, LLM-based log analysis, and automatically generated incident-cause and resolution suggestions. - These tools helped the team maintain an average response time of under ten minutes. ## Using Customer Experience to Improve TAM Work - Toss’s Seongmin Chun drew on previous experience working for a customer organization. - Understanding customer frustrations and the information needed during incidents influenced his communication and support practices. - The team used the PDCA cycle to continually improve integration guides, standardize repeated communications, and structure operational processes. - Effective TAM work means not only solving current problems but also ensuring the same problems do not happen again. ## Shared Challenges Across Companies - TAMs must balance customer expectations with internal development teams. - They operate in rapidly changing services with increasingly complex systems. - The role requires simultaneous understanding of technology, business priorities, and customer needs. - TAMs often appear to sit ambiguously between support, operations, development, and business, but their actual work involves structuring complex problems and mobilizing multiple teams. - The event characterized TAMs as technology-based problem solvers rather than simple support personnel. ## AI and the Future of TAM Work - AI is already being applied to: - Log analysis - Incident-cause recommendations - Operations guide generation - Automated responses to recurring inquiries - Anomaly detection - Document search and summarization - As AI handles repetitive responses, TAMs are likely to focus more on complex problem-solving, structural improvements, cross-team coordination, customer-experience design, and operational strategy. TAM CONNECT demonstrated that TAM organizations can learn significantly from one another. As technology and services become more complex, TAMs will likely become increasingly strategic, combining automation and AI with the judgment needed to improve systems, processes, and customer experiences.

apillmincident-managementfintech+4

gitlabMay 28, 2026

Claude Opus 4.8 on GitLab: Complex agentic work, less disruption (opens in new tab)

Claude Opus 4.8 is now available in GitLab Duo Agent Platform for complex, multi-step coding and agentic workflows. The model is designed to follow instructions more precisely over extended autonomous runs, reducing the need for human correction and intervention. It also supports mid-conversation system-prompt updates without invalidating the prompt cache, making it better suited to changing contexts. ## Improved Long-Horizon Agentic Execution - Handles complex workflows involving multiple tools and extended sequences. - Provides more comprehensive planning and reasoning. - Produces more accurate end states with fewer interruptions or redirects. - Interprets instructions more precisely than previous models. - Supports professional tasks beyond coding, including: - Document drafting - Data analysis - Structured knowledge work ## Mid-Conversation System Prompts - System instructions can change during an active session. - Prompt-cache validity is preserved when context changes. - This is useful when: - Files change on disk - Token budgets shift - User context is updated - Asynchronous information arrives ## Availability and Pricing - Available through model selection in Agentic Chat and across GitLab Duo agent workflows. - Runs on GitLab Credits. - GitLab Premium and Ultimate subscribers can use included credits. - New users can access it through a GitLab Duo Agent Platform trial or the GitLab Free tier. Teams seeking more reliable autonomous coding and documentation workflows can use Opus 4.8 in GitLab Duo to reduce manual oversight while agents complete longer, more complex tasks.

apiagentic-aidata-analysisgitlab-duo+3

awsApr 16, 2026

Introducing Anthropic’s Claude Opus 4.7 model in Amazon Bedrock | Amazon Web Services (opens in new tab)

Claude Opus 4.7 is now available in Amazon Bedrock as Anthropic’s most capable Opus model for coding, professional knowledge work, long-running agents, and visual tasks. It runs on Bedrock’s new inference engine, which dynamically schedules capacity, improves availability, queues requests during demand spikes, and provides zero operator access to prompts and responses. AWS positions the model as a production-ready upgrade to Opus 4.6, though teams may need to adjust prompts and agent harnesses. ## Model Improvements - **Agentic coding:** Stronger long-horizon autonomy, systems engineering, and complex code reasoning. - 64.3% on SWE-bench Pro - 87.6% on SWE-bench Verified - 69.4% on Terminal-Bench 2.0 - **Knowledge work:** Better document creation, financial analysis, and multi-step research. - Handles underspecified requests by making and explaining reasonable assumptions. - Self-verifies responses to improve first-pass quality. - 64.4% on Finance Agent v1.1. - **Long-running tasks:** Maintains coherence across its full 1-million-token context window while handling ambiguity and verifying results. - **Vision:** High-resolution image support improves analysis of charts, dense documents, and detailed screen interfaces. - **Adaptive thinking:** Dynamically allocates reasoning-token budgets based on request complexity. ## Bedrock Infrastructure and Scaling - The new inference engine uses updated scheduling and scaling logic to allocate capacity dynamically. - It prioritizes steady-state workloads while rapidly scaling capacity for changing demand. - During high demand, requests are queued instead of rejected. - Up to 10,000 requests per minute per account and Region are available immediately, with additional capacity available by request. - Zero operator access prevents AWS and Anthropic operators from viewing customer prompts and responses. ## Ways to Invoke the Model - Test Claude Opus 4.7 in the Amazon Bedrock console through **Playground**. - Use the Anthropic Messages API through: - Anthropic SDK integrations with Bedrock - `bedrock-mantle` endpoints - Use Bedrock-native APIs: - **Converse API** for multi-turn conversations and Guardrails integration - **Invoke API** for direct invocation and lower-level control - Invoke it with the AWS CLI using model ID `anthropic.claude-opus-4-7`. - The Anthropic Bedrock SDK can authenticate with AWS Signature Version 4 and submit Messages API requests programmatically. ## Availability - Initially available in: - US East (N. Virginia) - Asia Pacific (Tokyo) - Europe (Ireland) - Europe (Stockholm) - AWS directs users to the Bedrock model and pricing pages for regional availability updates. Teams seeking stronger coding agents, complex research workflows, or high-volume production inference can try Claude Opus 4.7 in Bedrock, while validating prompt and harness changes before migrating existing Opus 4.6 workloads.

apipythonamazon-bedrockagentic-coding+4

gitlabApr 8, 2026

GitLab Patch Release: 18.10.3, 18.9.5, 18.8.9 | GitLab Docs (opens in new tab)

GitLab released patch versions 18.10.3, 18.9.5, and 18.8.9 on April 8, 2026, addressing important security and bug fixes. Self-managed CE and EE installations should upgrade immediately, while GitLab.com is already patched and GitLab Dedicated customers need no action. The fixes cover unauthorized access, denial-of-service vulnerabilities, code injection, XSS, and information disclosure. ## Release Scope and Upgrade Guidance - The patches apply to GitLab Community Edition and Enterprise Edition. - Administrators should upgrade installations affected by the listed vulnerabilities to the latest supported patch release. - GitLab issues describing security vulnerabilities will become public 30 days after the release in which they were fixed. - Patch releases are generally issued on the second and fourth Wednesdays, with urgent ad-hoc releases for critical vulnerabilities. ## Authentication and Authorization Fixes - **CVE-2026-5173 (CVSS 8.5):** Authenticated users could invoke unintended server-side methods through WebSocket connections. - **CVE-2026-2619 (CVSS 4.3):** Auditor users could modify vulnerability flag data in private projects through the AI detection API. - **CVE-2026-1752 (CVSS 4.3):** Developers could modify protected environment settings through authorization flaws in the Environments API. - **CVE-2026-2104:** CSV exports could expose confidential issues assigned to other users because of insufficient authorization checks. ## Denial-of-Service Vulnerabilities - **CVE-2026-1092 (CVSS 7.5):** Unauthenticated attackers could crash or disrupt services through malformed JSON sent to the Terraform state lock API. - **CVE-2025-12664 (CVSS 7.5):** Repeated unauthenticated GraphQL queries could cause denial of service. - **CVE-2026-1403 (CVSS 6.5):** Authenticated users could disrupt Sidekiq workers by importing malformed CSV files. - **CVE-2026-1101 (CVSS 6.5):** Authenticated users could overload GitLab through improperly validated GraphQL SBOM queries. ## Code Execution and Cross-Site Scripting - **CVE-2026-1516 (CVSS 5.7):** Crafted Code Quality report content could leak the IP addresses of users viewing the report. - **CVE-2026-4332 (CVSS 5.4):** Authenticated users could execute arbitrary JavaScript in other users’ browsers through customizable analytics dashboards. ## Information Disclosure - **CVE-2025-9484 (CVSS 4.3):** Certain GraphQL queries could reveal other users’ email addresses to authenticated users. - The release also fixes CSV export authorization issues that could expose confidential issue data. Administrators of self-managed GitLab CE or EE instances should apply 18.10.3, 18.9.5, or 18.8.9 as soon as possible, depending on their supported release branch.

apigitlabgraphqlcve+4

gitlabApr 7, 2026

Streamline test management with SmartBear QMetry GitLab component (opens in new tab)

The SmartBear QMetry GitLab Component automates the transfer of test results from GitLab CI/CD pipelines into QMetry Test Management Enterprise. By publishing JUnit, TestNG, and other supported results automatically, it removes manual uploads and provides a centralized, traceable view of testing. The integration helps teams accelerate release decisions while supporting compliance and audit requirements. ## Why Integrate GitLab with QMetry? - **Eliminate manual uploads:** Test results are transferred automatically after pipeline execution, reducing effort and preventing outdated or inconsistent records. - **Improve traceability:** Teams can connect requirements, test cases, executions, commits, builds, and pipelines in a single audit trail. - **Accelerate feedback:** QA teams, product managers, and stakeholders gain access to results immediately after tests finish. - **Support regulated development:** Centralized, versioned test records help organizations in aerospace, financial services, automotive, and medical-device industries demonstrate test coverage and compliance. - **Enable AI-driven insights:** QMetry can analyze execution history to identify flaky tests, predict failures, and suggest optimization opportunities. ## GitLab–SmartBear Integration - The component is part of a broader partnership connecting GitLab’s CI/CD and DevSecOps capabilities with SmartBear’s testing and quality-management tools. - The integration is intended for organizations that need centralized visibility across complex or regulated software-development lifecycles. - QMetry acts as the system of record for test planning, execution, tracking, and reporting. ## Requirements and Test Result Flow Before configuring the integration, teams need: - A GitLab project with automated tests that generate JUnit XML, TestNG XML, or another supported format. - A QMetry Test Management Enterprise account with API access enabled. - A QMetry API key with permission to upload test results. - An existing QMetry project. - Basic knowledge of GitLab CI/CD and `.gitlab-ci.yml`. - Optionally, a configured QMetry test suite for better organization. The automated flow is: - GitLab runs unit, integration, end-to-end, or other automated tests. - The tests generate result files. - The QMetry component runs as a pipeline job. - It reads the result files and uploads them to QMetry through the API. - QMetry processes the results for reporting and analysis. ## Obtaining QMetry API Credentials - Log in to QMetry Test Management Enterprise. - Open the user profile and navigate to **Settings** or **API Access**. - Generate a named API key, such as `GitLab CI/CD Integration`. - Grant the key write access for test-result uploads. - Copy the key immediately because it is displayed only once. - Record the QMetry instance URL, typically in the form `https://your-company.qmetry.com`. The API key should be treated like a password. It should not be committed to `.gitlab-ci.yml` or stored in plain text; GitLab CI/CD variables should be used to protect it. The component provides a practical way to make QMetry the centralized source of truth for pipeline testing. Organizations should secure the API credentials, configure the component in their GitLab pipeline, and continuously publish results so teams can improve visibility, traceability, and release confidence.

apiaigitlabci-cd+4

awsMar 31, 2026

Announcing the AWS Sustainability console: Programmatic access, configurable CSV reports, and Scope 1–3 reporting in one place | Amazon Web Services (opens in new tab)

The AWS Sustainability console is a standalone service that centralizes AWS emissions reporting and sustainability resources. It builds on the Customer Carbon Footprint Tool while adding independent permissions, customizable reports, fiscal-year support, and programmatic access. The underlying emissions data and methodology remain unchanged, but organizations now have more flexible ways to analyze and automate sustainability reporting. ## Independent Sustainability Access - Sustainability professionals can access emissions data without receiving AWS Billing permissions. - The console uses a permissions model separate from the Billing console. - Historical emissions data is available back to January 2022 at no additional cost. ## Scope 1–3 Emissions Reporting - Reports AWS-related emissions in metric tons of carbon dioxide equivalent (MTCO2e). - Covers: - **Scope 1:** Direct emissions from controlled sources, such as data center fuel use. - **Scope 2:** Indirect emissions from purchased energy. - **Scope 3:** Value-chain emissions, including server manufacturing and data center construction. - Data can be viewed by AWS Region and service, including Amazon EC2, Amazon S3, and CloudFront. - Both market-based method (MBM) and location-based method (LBM) calculations are supported. - The methodology is unchanged from the Customer Carbon Footprint Tool and has been independently verified by Apex. ## Configurable Reports and Fiscal Years - The Reports page provides preset monthly and annual emissions reports. - Users can create custom CSV reports by selecting: - Fields - Time granularity - Date ranges - Services, Regions, and other filters - Organizations can configure fiscal years that differ from the calendar year. - Once configured, data views and exports use the organization’s fiscal quarters and reporting periods. ## API and AWS CLI Access - A new API and AWS SDK support integration with: - Internal reporting pipelines - Sustainability dashboards - Compliance workflows - Teams can retrieve emissions for specific periods across many accounts without creating a data export. - Custom account groupings can be used even when they do not match the AWS Organizations hierarchy. - The AWS CLI command `get-estimated-carbon-emissions` returns emissions values, time periods, units, and model versions for MBM and LBM data. ## Availability and Future Development - The console is accessible through the AWS Management Console. - It complements existing Data Exports, allowing users to investigate emissions visually and automate stakeholder reporting. - AWS plans to expand the console with additional capabilities and publishes feature and methodology updates through its Release notes page. Organizations can begin using the free AWS Sustainability console immediately to explore emissions trends, create tailored reports, and connect AWS carbon data to existing sustainability processes.

apiaws-clicarbon-footprintaws-sustainability+3

awsMar 26, 2026

Customize your AWS Management Console experience with visual settings including account color, region and service visibility | Amazon Web Services (opens in new tab)

AWS has expanded User Experience Customization (UXC) to let administrators tailor the Management Console by account color, visible Regions, and visible services. These settings help teams distinguish accounts and reduce clutter by showing only relevant resources. They affect console appearance only and do not restrict access through the CLI, SDKs, APIs, or Amazon Q Developer. ## Account Color Customization - Administrators can assign a color to an AWS account through **Account display settings**. - The color appears in the console navigation bar to make account purpose easier to recognize. - Teams can use colors such as: - Orange for development - Light blue for testing - Red for production ## Region Visibility - Administrators can configure which AWS Regions appear in the console’s Region selector. - They can either show all available Regions or select a specific list. - After saving, only the chosen Regions appear in the navigation bar. - This reduces unnecessary scrolling and helps users focus on approved or relevant Regions. ## Service Visibility - Administrators can select which AWS services appear in the **All services** menu and console search results. - Services can be searched for or selected by category, such as Popular services. - Hidden services are removed from the console interface but remain accessible through programmatic tools. ## Programmatic Configuration - Account customization can be managed through the `AWS::UXC::AccountCustomization` CloudFormation resource. - The resource supports: - `AccountColor` - `VisibleServices` - `VisibleRegions` - Example configurations can expose services such as `s3`, `ec2`, and `lambda`, while limiting Regions to `us-east-1` and `us-west-2`. - Templates can be deployed with the AWS CLI using `aws cloudformation deploy`. AWS administrators can use these settings to create a clearer, more focused console experience without changing permissions or underlying account access.

apiawsclicloudformation+3

lineMar 25, 2026

Advancing Guardrail Models through Automated Vulnerability Collection and Generation Using Coding Agents (opens in new tab)

LLM guardrails must detect prompt injection and jailbreak attempts without blocking legitimate requests that merely contain security-related keywords. The post argues that benchmark scores alone do not reflect production performance, especially false positives caused by missing input diversity. It presents a Codex-based, automated testing pipeline that generates categorized test data, evaluates the guardrail model, and analyzes failures reproducibly. ## The Gap Between Benchmark and Production Performance - The initial guardrail model performed well on external benchmarks but produced unexpected false positives in production-like tests. - Legitimate requests containing terms such as “ignore,” “bypass,” “override,” “system prompt,” or “jailbreak” were sometimes classified as attacks. - Examples included: - Development questions about temporarily bypassing authentication in a local test environment. - Educational requests about jailbreak techniques and defensive guidelines. - The core issue was insufficient representation of real-world input diversity, not simply poor model quality. - This motivated an automated environment for repeatedly discovering and analyzing guardrail weaknesses. ## Using Codex as a Test Automation Tool - The team adapted coding agents from software development tasks to complex, repeatable security testing. - Codex was used through its CLI capabilities to: - Read and create project files. - Edit code. - Execute evaluation scripts. - The pipeline relies on three Codex concepts: - **AGENTS.md:** Defines global rules, project conventions, commands, and security constraints. - **Sub-agents:** Allow a main orchestrator to delegate independent category tests to parallel worker agents. - **Skills:** Package repeatable procedures, input/output specifications, prompts, and scripts into reusable modules. ## Category-Based Experiments - Instead of sending thousands of random samples, experiments are divided into vulnerability and false-positive categories. - Example categories include: - Normal development or IT requests containing security-related keywords. - Educational or preventive requests involving sensitive topics such as jailbreaks or drug abuse prevention. - Categorization improves: - Root-cause analysis. - Parallel execution through independent workers. - Context clarity. - Regression testing after model changes. ## Separate Generation and Evaluation Skills ### `synthetic-generator` - Creates test queries according to each category’s specification. - Enforces constraints such as: - Attack type. - Sentence length. - Safe or dangerous target labels. - Produces varied, realistic phrasing and stores the dataset as JSONL. ### `injection-classifier` - Sends generated inputs to the guardrail model API through Python scripts. - Compares predictions with ground-truth labels. - Calculates false-positive and false-negative statistics. - Stores the original text, labels, predictions, and metrics in a consolidated JSONL file. Separating these procedures into skills provides intermediate artifacts for debugging, fixed input/output contracts for reproducibility, and independent maintenance of generation and evaluation logic. ## Pipeline Architecture - A **main agent**: - Reads `AGENTS.md` and `TEST_CATEGORY.md`. - Determines categories, sample counts, and constraints. - Creates and assigns work to category-specific workers. - Collects completion reports and verifies the run. - Each **category worker**: - Generates `input.jsonl` using `synthetic-generator`. - Evaluates the guardrail model using `injection-classifier`. - Produces `result.jsonl` with predictions and metrics. - Analyzes false positives and false negatives. - Writes a Markdown analysis report. - Stores outputs under `outputs/<run_id>/`, organized by category. ## Results and Practical Recommendation The pipeline enables systematic, repeatable testing rather than isolated discovery of misclassifications. For production guardrails, teams should combine benchmark evaluation with categorized real-world simulations, modular generation and evaluation steps, parallel test agents, and preserved JSONL artifacts for debugging and regression analysis.

apipythonprompt-injectioncodex+4

lineMar 19, 2026

Utilizing SLI/SLO to Improve Reliability Part 1: SLI/SLO Framework and the Development Story of Service Status Check Tool LINE Status (opens in new tab)

Repeated SLI/SLO adoption revealed a common process that could be standardized across services. The team turned that process into a reusable framework and built “LINE Status,” an internal tool that automatically presents service health according to user experience rather than raw alerts. Together, these initiatives create a shared organizational language for understanding reliability and its impact on users. ## A Reusable SLI/SLO Framework After applying SLI/SLOs to several platforms and services, the SRE team identified recurring patterns independent of service type. They organized these patterns into a five-stage framework: - **Select critical user journeys (CUJs) and define SLIs** - Identify the experiences most important to users. - Define measurable SLIs that represent those experiences. - **Design instrumentation and metrics** - Build or adapt metrics suitable for each CUJ. - Use standardized naming based on Prometheus or OpenTelemetry. - **Create dashboards and recording rules** - Provide Grafana dashboards for quickly assessing SLO achievement. - Precompute complex PromQL operations to improve query performance. - **Set SLOs and alerts** - Begin with flexible targets, such as 99.9% availability over a 28-day rolling window, allowing roughly 40 minutes of downtime. - Define runbooks for responding to alerts. - Refine targets after operational data and experience accumulate. - **Establish error-budget governance** - Balance release speed against reliability. - Review objectives monthly or quarterly. - Adjust SLOs and processes as needed. The framework is currently distributed as a Confluence template containing guidance and FAQs, reducing the communication effort required from SREs during initial adoption. ## Moving from Alerts to User-Centered Service Status As more services adopted SLI/SLOs, the team wanted a consistent way to understand the health of services they did not directly operate. - The existing public LINE Status API page focused on external users and was updated manually during major incidents. - The new internal tool was intended to: - Represent the status of individual service components. - Update automatically from SLI/SLO alerts and outage data. - Show whether user experience was being affected. - Rather than simply reflecting whether an alert or outage existed, status was based on CUJ-related SLI performance and SLO achievement. - Only representative, high-value CUJs were exposed, avoiding unnecessary technical detail. ## LINE Status Architecture and Interface LINE Status was designed as more than an alert list. It collects events through webhooks, stores them in a separate database, and uses that data to track both current status and historical changes. - Technical SLI/SLO terms are translated into user-facing functions such as “Message Sending” or “Read Receipts.” - Status colors provide an immediate overview: - Green: normal - Yellow: event detected - Red: outage - The main page provides: - An overview of all services. - CUJ status within each service card. - AI-generated one-line summaries. - Service detail pages provide: - Recently affected items near the top. - Timeline-based event displays. - Monthly historical events. - The history page shows: - The scope of impact for each service during an event. - Past events organized by month. The initial implementation took about a month and was refined through colleague feedback. The author also used AI-assisted “vibe coding” for the frontend, emphasizing that clear, detailed requirements were more important than the development tool itself. ## Connecting the Framework and LINE Status Once a service adopts SLI/SLOs through the framework, it can be registered in LINE Status. This connects the definition of reliability objectives with an organization-wide view of service health. - Developers and operators can use the same CUJ-based standards. - Teams can focus on whether users are affected instead of interpreting isolated alerts. - During incidents, the tool helps identify impacted experiences quickly. - Over time, the approach may improve decision-making speed and cross-team communication. The team plans to refine CUJs, SLIs, and status-transition rules through continued operational experience. The practical goal is to make SLI/SLOs a common language for describing service health, enabling reliability practices to scale without depending heavily on individual teams or specialists.

apidatabase-designprometheusopentelemetry+3

awsMar 13, 2026

Twenty years of Amazon S3 and building what’s next | Amazon Web Services (opens in new tab)

Amazon S3 began in 2006 as a simple web service for storing and retrieving objects, but its emphasis on security, durability, availability, performance, and elasticity enabled it to become foundational infrastructure. Over two decades, it scaled from roughly one petabyte to hundreds of exabytes while preserving API compatibility, reducing prices, and expanding beyond object storage. Amazon’s long-term vision is for S3 to serve as a universal foundation for data, analytics, and AI workloads. ## The Original S3 Philosophy - S3 introduced two basic operations: - `PUT` to store an object - `GET` to retrieve it - The service abstracted away complex infrastructure so developers could focus on applications. - Its five enduring design principles are: - **Security:** Data is protected by default. - **Durability:** Designed for 11 nines of durability, with a lossless operating model. - **Availability:** Failure is assumed and handled throughout the system. - **Performance:** Storage capacity can grow without degrading performance. - **Elasticity:** Capacity expands and contracts automatically. ## From One Petabyte to Hundreds of Exabytes - At launch, S3 had approximately: - One petabyte of capacity - 400 storage nodes across 15 racks and three data centers - 15 Gbps of bandwidth - A maximum object size of 5 GB - A price of $0.15 per GB - Today, S3: - Stores more than 500 trillion objects. - Serves over 200 million requests per second. - Operates across 123 Availability Zones in 39 AWS Regions. - Supports objects up to 50 TB—10,000 times larger than the original limit. - Storage prices have fallen by roughly 85%, to slightly above 2 cents per GB. - S3 Intelligent-Tiering has saved customers more than $6 billion in storage costs. - The S3 API has become an industry standard, with many other storage systems offering compatible interfaces. ## Backward Compatibility and Long-Term Reliability - Code written against S3 in 2006 still works without modification. - AWS has repeatedly replaced disks, storage systems, and request-processing code while preserving access to older data. - This compatibility reflects S3’s goal of remaining infrastructure that “just works” despite continuous internal change. ## Engineering for Durability and Scale - Microservices continuously inspect every byte across the fleet. - Auditor services detect degradation and automatically trigger repair and re-replication. - Automated formal methods mathematically verify correctness in areas such as: - The index subsystem - Cross-Region replication - Access policies - AWS has progressively rewritten performance-critical components in Rust over the past eight years. - Rust improves performance while preventing memory-safety bugs and other classes of errors at compile time. - S3 follows the principle that scale should improve the service: larger, more distributed workloads become increasingly decorrelated, improving reliability for all customers. ## S3 as a Foundation for Data and AI Amazon’s future vision is for customers to store data once in S3 and work with it directly, avoiding costly copies and specialized systems. - **S3 Tables** provides managed Apache Iceberg tables with automated maintenance to improve query performance and reduce storage costs. - **S3 Vectors** supports semantic search and retrieval-augmented generation, with up to 2 billion vectors per index and sub-100 ms query latency. - Within five months of launch, customers created over 250,000 indexes, ingested more than 40 billion vectors, and executed over 1 billion queries. - **S3 Metadata** enables centralized, faster data discovery without recursively listing large buckets. These additions extend S3 from inexpensive object storage into a broader platform for analytics, search, and AI while retaining its scale and cost advantages.

apidatabase-designrustmicroservices+4

discordMar 6, 2026

Discord Patch Notes: March 6, 2026 (opens in new tab)

Discord’s March 6, 2026 patch focuses on safer mentions, faster desktop startup, accessibility, and a broad collection of platform-specific bug fixes. Escaped `@everyone` and `@here` mentions are now correctly ignored by the backend, preventing accidental mass notifications. Discord also reports an 11.8% median improvement in desktop time-to-interactive after changing API payload ordering. ## Safer Mention Handling - Escaped mentions such as `\@everyone` previously appeared harmless in the client but could still notify roles when sent. - Backend handling now respects escape characters for `@everyone` and `@here`, ensuring these messages do not trigger mentions. - The change addresses cases where users received no warning before unintentionally notifying large server populations. ## Desktop Performance - Discord changed the order of API payloads sent to desktop clients. - The update reduced median launch time, or p50 time-to-interactive, by 11.8%. - The improvement builds on navigation performance work released the previous week. ## Accessibility Improvements - Discord completed a broad accessibility pass covering Quest, Events, Profiles, Activities, and Nitro surfaces. - The changes are intended to improve screen-reader navigation and usability across these areas. ## General and Platform Fixes - Non-Nitro users can once again forward messages containing large attachments from Nitro users. - iOS startup times after a full device restart were fixed; an asset request had been competing with the busy boot-time background queue. - Mobile animations no longer remain stuck mid-transition. - League of Legends game invites and Overlay “Join” invites were repaired. - Android fixes include the Forest theme gradient, duplicate server-invite information, modal layering, role colors, and server-onboarding alignment. - Search-result keyboard selection no longer remains stuck on the first item. - Desktop fixes address private-channel role setup, oversized hyperlinks, broken embeds, Quick Switcher shortcuts, tooltip links, and copying webhook URLs without confirmation. - Server administration fixes include role sorting, role-selector scrolling, onboarding dropdown positioning, audit-log deletion reasons, permission-panel alignment, and non-removable role controls. - iOS fixes restore back-swipe navigation, correct switch styling, reduce overly aggressive settings scrolling, and prevent the device from being kept awake unnecessarily. - Browser and mobile layout issues were corrected across server lists, profiles, Nitro Home, boost flows, and message controls. Discord recommends trying the iOS TestFlight build for early features and reporting remaining bugs through the community bug megathread. Fixes had been merged but could still be rolling out gradually across platforms.

apidiscordaccessibilityandroid+3