Gigabee AI

Chat with Bee, earn Honey. Decentralized inference on contributor GPUs worldwide. $GB
CA : 7NcMKMrXPBVCWPcs9SSqnF6ZGy5neAtzTZpFqZqLquaP

[Gigabee AI @Gigabee_]

Gigabee models are now live on Hermes Agent.

Connected bee-hover via the OpenAI-compatible endpoint at https://t.co/ebwL04FgpW no SDK changes, no wrapper, just a base URL and a giga_ API key.

Hermes detected all 3 Gigabee models (bee-nano, bee-hover, bee-glide) automatically and started routing inference through the decentralized GPU network immediately.

Any OpenAI-compatible client works the same way. Gigabee is an open inference layer plug it in wherever you already use AI.

base_url: https://t.co/ebwL04FgpW
model: bee-hover

@NousResearch

[Gigabee AI @Gigabee_]

Staking Phase 1 UI & Flow Coming Soon

Phase 1 of GPU staking is moving from spec to screen. Workers who stake will unlock a higher revenue share (85% vs. the standard 75%) on jobs they serve, and

we're now designing the staking dashboard: stake/unstake flow, live earnings preview, and stake status right inside the Earn page.

This will be the first step toward a fully on-chain reputation and incentive layer for the worker network more details to follow as the UI locks in. solana:7NcMKMrXPBVCWPcs9SSqnF6ZGy5neAtzTZpFqZqLquaP

[Gigabee AI @Gigabee_]

Upcoming: A Sharper Bee Code

Bee Code, our code-specialist model, is getting a quality pass on the roadmap. We're evaluating stronger coding-tuned backbones and refining the system prompt so Bee Code will handle multi-file reasoning, debugging, and longer context windows more reliably closing the gap with dedicated coding assistants while staying inside the Gigabee credit system.

Rollout will be incremental as we benchmark candidate models against real developer workloads before switching the default. solana:7NcMKMrXPBVCWPcs9SSqnF6ZGy5neAtzTZpFqZqLquaP

[Gigabee AI @Gigabee_]

@P0Systems @TencentHunyuan very interesting.🐝

[Gigabee AI @Gigabee_]

Coming Soon:
Bee Studio Connected Video Generation

We're planning Bee Studio, the next evolution of Bee Reel: instead of generating one isolated clip at a time, Bee Studio will let you chain multiple generations into a continuous sequence each new clip picking up visually and narratively where the last one left off, so you can build longer-form videos scene by scene.

Think of it as a storyboard mode for AI video: prompt each beat, preview it, and stitch them into one flowing reel. Early architecture planning is underway now. solana:7NcMKMrXPBVCWPcs9SSqnF6ZGy5neAtzTZpFqZqLquaP

[Gigabee AI @Gigabee_]

Next Up for Bee Reel solana:7NcMKMrXPBVCWPcs9SSqnF6ZGy5neAtzTZpFqZqLquaP

Bee Reel improvements are on the roadmap: better prompt handling, faster generation times, and more consistent output quality across portrait and landscape formats. We're tuning this based on real usage patterns to make every reel generation smoother than the last.

Look out for these upgrades rolling out in upcoming updates.

[Gigabee AI @Gigabee_]

Coming Soon: Gigabee × @openclaw Integration

We're working on official support to plug Gigabee models (bee-nano, bee-hover, bee-glide, bee-code) into OpenClaw as a custom model provider. Once shipped, anyone running OpenClaw's self-hosted agent gateway will be able to route their agent's chat completions straight through the Gigabee network same decentralized inference, same credit-based pricing, reachable from Discord, Telegram, Slack, and every other channel OpenClaw supports.

Internal testing of the integration path is already underway. Full setup guide will land in our docs once it ships. solana:7NcMKMrXPBVCWPcs9SSqnF6ZGy5neAtzTZpFqZqLquaP

[Gigabee AI @Gigabee_]

MAJOR UPDATE !
Introducing Bee Reel Live Now on Gigabee.

Bee Reel is Gigabee's new AI video generation feature, now live and ready to use directly inside your chat with Bee. Powered by the bytedance/seedance-1-lite model, it turns any text prompt into a short, high-quality video no separate app or subscription required, just your existing Gigabee credits.

To use it, open a chat with Bee and click the Reel button in the composer toolbar. Write a clear, descriptive prompt for the video you want, choose your orientation (portrait or landscape) and duration (4, 6, or 8 seconds), then confirm.

Credits are charged upfront
75 credits for 4 seconds,
115 for 6 seconds, or 150 for 8 seconds, the same price regardless of orientation.

Once you confirm, Bee Reel starts processing your request, which usually takes anywhere from 30 seconds to about a minute.

You'll see a progress indicator right in the chat while it works. When it's done, a 720p MP4 video appears in your conversation with a Download button, so you can save it straight to your device.

If a generation fails for any reason, your credits are automatically refunded, so you're never charged for a video that doesn't come through. And in line with Gigabee's privacy-first approach, your prompts aren't stored on our servers each video is generated fresh and delivered straight to you. solana:7NcMKMrXPBVCWPcs9SSqnF6ZGy5neAtzTZpFqZqLquaP

[Gigabee AI @Gigabee_]

All Gigabee Models Live
Here's a complete overview of every model currently available on the Gigabee network:

🐝Bee Nano : The lightest and fastest model on the network. Ideal for quick questions, short answers, and everyday AI tasks. Costs 5 credits per message, making it the most accessible entry point for new users.

🐝Bee Hover : The balanced all-rounder. Handles writing, summarizing, research, and multi-turn conversations with solid depth. 10 credits per message and the recommended model for most use cases.

🐝Bee Glide : The most capable chat model. Built for complex reasoning, detailed explanations, and long-form output where quality matters more than speed. 15 credits per message.

🐝Bee Code : Powered by Qwen2.5-Coder 14B, purpose-built for developers. Writes, debugs, refactors, and explains code across all major languages. 20 credits per message.

🐝Bee Echo : Text-to-speech voice generation. Converts any written text into natural-sounding audio with 6 voice styles to choose from. Output is delivered as a downloadable MP3, playable directly in your browser. Priced at 5 credits per 1,000 characters.

Coming soon: Bee Reel AI video generation. Currently in active development.

Found a bug or have feedback on any model? Reach out to the team or join our Telegram community every report helps us improve.

We're building this openly and your input directly shapes what gets fixed and what gets built next. 🐝

[Gigabee AI @Gigabee_]

UX Improvement

The core UI is functional chat works, the earn page shows quality scores and earnings, and workers can see their TPS, completion rate, and suspension status since v1.6.0. The gaps are in the moments where something is unclear or goes wrong. A new user lands with 10 free credits and no signal about what each model costs before sending a message. On mobile the layout compresses poorly, which matters because GPU workers check their earnings from their phones as often as from a desktop. The worker dashboard also lacks a per-job log, suspension explanation, and solana:7NcMKMrXPBVCWPcs9SSqnF6ZGy5neAtzTZpFqZqLquaP earnings projection workers can see their score but not understand why it changed.

Error states across chat and earn are too generic. When a job times out or no workers are available, the user sees a spinner or a plain error with no context, no retry estimate, and no indication of whether it's a network issue or their own account. These will be replaced with specific, actionable messages that reflect the actual distributed failure mode "Network busy, retrying in 3s" instead of silence, and a live worker availability indicator so users understand what's happening on the network side before they assume something is broken on theirs.

[Gigabee AI @Gigabee_]

Job Distribution Across Active GPUs

The current job dispatch uses weighted random selection. A worker's probability of receiving a job is proportional to its quality score higher score, higher odds. This keeps quality high and incentivizes good performance, which is the right foundation. The problem shows up at the edges: new workers with no job history start with a neutral score of 0.5 and face a cold-start disadvantage immediately, and consistently top-scoring workers absorb a disproportionate share of total traffic while mid-tier workers with decent-but-not-top scores sit at low utilization.

Low utilization is a network-level problem. If 40% of registered GPUs are rarely selected, the network can't absorb traffic bursts reliably. Workers who earn little churn out of the pool. New workers who can't build reputation early give up before their score stabilizes. The eligible pool shrinks precisely when demand grows the opposite of what a decentralized network needs.

Three changes are planned to address this. First, a reputation ramp for new workers: the first 20 jobs are evaluated with wider scoring tolerance, giving new GPUs a fair window to establish real history before competing on equal terms with workers that have hundreds of jobs. Second, a soft utilization cap so that no single worker absorbs more than a configurable percentage of total traffic in a rolling time window, pushing overflow to the next-best eligible worker rather than re-rolling the same lottery. Third, equivalent-quality tiebreaking based on geographic spread if two workers have similar scores, the one that increases geographic distribution of active GPUs. solana:7NcMKMrXPBVCWPcs9SSqnF6ZGy5neAtzTZpFqZqLquaP

[Gigabee AI @Gigabee_]

@MiroslavErm That's not how it works, the way gigabee works is if you want to earning you have to provide gpu for ai computing from the user side who uses gigabee model. payment is paid directly to worker if their gpu gets job

[Gigabee AI @Gigabee_]

This is what a real network looks like at the foundation stage. Every token is a real job served by a real GPU. Every job adds to the quality data that makes the network smarter and more reliable over time. We're not inflating stats. We're building something that compounds.

Each system update better job routing, worker quality scoring, latency improvements moves the chart. Slowly at first, then not slowly at all.

Want to be part of it?

→ Chat with Bee at https://t.co/SLWdSHcqji 5 models live, free credits to start
→ Run a worker, earn solana:7NcMKMrXPBVCWPcs9SSqnF6ZGy5neAtzTZpFqZqLquaP for every job your GPU serves
The hive is growing. 🐝

[Gigabee AI @Gigabee_]

Token generation on the Gigabee network has been growing every day since launch.

Each bar on that chart is real compute. Real jobs. Real earnings distributed to GPU contributors around the world.

Day 1 was quiet. Today the bars are taller. Tomorrow they'll be taller still.

The hive is alive. 🐝

[Gigabee AI @Gigabee_]

Latency Optimization

First-token latency (TTFB) is already tracked per worker in real time, rolling across the last 20 jobs, and it contributes 20% to each worker's quality score. The data pipeline is there. The problem is that the orchestrator doesn't yet use TTFB data to make routing decisions before a job is assigned it only updates scores after the fact. A worker with a consistently high TTFB stays in the eligible pool at reduced probability, but it can still receive jobs and deliver slow first tokens to real users.

The two biggest structural causes of high TTFB are cold GPU state model not loaded in memory, requiring a disk swap before inference starts and no queue-depth signal. A worker already processing one job receives the next one with the same probability as an idle worker. The user waits for both the active job to release GPU memory and the new job to begin. Neither of these requires geographic routing to fix.

The immediate optimization is queue-depth-aware dispatch: workers report their current processing state in the heartbeat, and the orchestrator skips workers that are mid-job unless no idle workers are available. A pre-warm signal is also in scope the orchestrator will send a lightweight ping to idle workers 30 seconds before expected high-traffic periods based on recent usage patterns. Geographic affinity routing, where users are matched to nearby workers to reduce network hop latency, is planned for a later phase once the base routing improvements are stable. solana:7NcMKMrXPBVCWPcs9SSqnF6ZGy5neAtzTZpFqZqLquaP

[Gigabee AI @Gigabee_]

@tonyGewrit https://t.co/0sUCGb1DrI

[Gigabee AI @Gigabee_]

@Paul250889 stay with us🐝 solana:7NcMKMrXPBVCWPcs9SSqnF6ZGy5neAtzTZpFqZqLquaP

[Gigabee AI @Gigabee_]

@El_DoN_EV 🐝🐝🐝🐝🐝

[Gigabee AI @Gigabee_]

Staking in the Credit & Earning Economy

Gigabee runs on its own native token solana:7NcMKMrXPBVCWPcs9SSqnF6ZGy5neAtzTZpFqZqLquaP. All payments, earnings, and economic activity within the network use solana:7NcMKMrXPBVCWPcs9SSqnF6ZGy5neAtzTZpFqZqLquaP exclusively.
Users buy credits with solana:7NcMKMrXPBVCWPcs9SSqnF6ZGy5neAtzTZpFqZqLquaP to run inference. Workers earn solana:7NcMKMrXPBVCWPcs9SSqnF6ZGy5neAtzTZpFqZqLquaP for every job they serve. The current earning rate is 75% of job value per completed request, paid directly in solana:7NcMKMrXPBVCWPcs9SSqnF6ZGy5neAtzTZpFqZqLquaP to the worker's wallet on Solana.

Staking is the next planned layer on top of active earnings. Workers who stake solana:7NcMKMrXPBVCWPcs9SSqnF6ZGy5neAtzTZpFqZqLquaP back into the network will earn 85% per job instead of 75%. The extra 10% is the yield on your commitment funded by real job revenue, not by token emission or inflation. Staked workers will also receive a weighted routing advantage, meaning more jobs, more consistently, compounding the earnings advantage further.

The design keeps the incentive honest: staking doesn't mint new solana:7NcMKMrXPBVCWPcs9SSqnF6ZGy5neAtzTZpFqZqLquaP or dilute existing holders. It redistributes a larger share of actual network revenue to workers who signal long-term alignment with the protocol. Workers that stake but consistently underperform will lose their routing priority through quality score degradation so the advantage rewards both commitment and real contribution, not just capital locked. This feature is in active planning and will be opened for community feedback before implementation begins.

[Gigabee AI @Gigabee_]

Native GPU Worker Spec Update

When a native GPU worker registers on Gigabee today, it declares its type (browser or native), a benchmark TPS reading, and an array of model identifiers it can serve.

The orchestrator also verifies a SHA-256 hash of the model weights file against a known-good registry so a worker claiming to run bee-code can be checked against the expected hash of qwen2.5-coder:14b before it's trusted with real jobs. This foundation is already in place.

What's missing is a structured capability manifest that covers VRAM, quantization level, and maximum context window.
Without these, the orchestrator routes based on model name alone. A GPU listing bee-glide might have 12GB VRAM and run a Q4-quantized version of llama3.3:70b that degrades on long contexts the system has no way to detect this until the job fails and the quality score drops.

The planned spec update defines tiered requirements that workers self-declare:
Nano and Hover tier workers need at least 6–8GB VRAM with 7B–13B parameter models.
Glide and Code tier workers require 16–24GB+ for 33B+ models at higher quantization levels.

Workers that register within spec receive a warm-up grace period before quality scoring begins in full. Those that misreport capabilities are demoted based on job failure rates. The hash verification system already handles integrity the new spec extends that to hardware claims. solana:7NcMKMrXPBVCWPcs9SSqnF6ZGy5neAtzTZpFqZqLquaP

[Gigabee AI @Gigabee_]

AI Model Optimization

Gigabee currently runs five active inference models: Bee Nano for lightweight tasks at 5 credits, Bee Hover as the balanced general-purpose model at 10 credits, Bee Glide for high-quality output at 15 credits, Bee Code for programming tasks at 20 credits, and Bee Echo for text-to-speech at 5 credits per request. Image generation is also available at 20 credits. For users without credits, the system falls back automatically to free-tier models via OpenRouter so no request goes unanswered.

The models themselves perform well. The gap is in dispatch logic. Context-length is not checked before a job is assigned, meaning a long conversation can land on a GPU that would time out serving it. There is no automatic tier downgrade when a primary model is overloaded, and cold GPUs receive jobs at the same probability as warm ones the only signal used today is quality score, not readiness state.

Planned improvements include a context-length pre-check before dispatch, a fallback chain within each tier so saturation at the primary doesn't stall the queue, and a cold-start penalty that reduces routing probability for GPUs that have been idle for over 10 minutes unless they pass a warm-up probe. These changes don't touch the models they make the existing five models land more reliably under all conditions. solana:7NcMKMrXPBVCWPcs9SSqnF6ZGy5neAtzTZpFqZqLquaP

[Gigabee AI @Gigabee_]

@tonyGewrit This change improves the scoring for native GPU workers so that jobs are distributed evenly.

[Gigabee AI @Gigabee_]

Worker Quality Scoring v1.6.0

The Problem

Every GPU worker in the Gigabee network previously had a reputation score calculated once at registration based on a benchmark test run before any real jobs were served. A worker with a great benchmark could degrade silently over time due to thermal throttling, network issues, or unstable GPU load, and the network had no mechanism to detect or respond to it. All workers were treated nearly equally regardless of how they actually performed.
What's New

Starting with v1.6.0, reputation is no longer static. After every single completed job success or failure the orchestrator recalculates the worker's quality score using three real signals: how consistently the worker finishes its assigned jobs, how fast it generates tokens compared to its own benchmark, and how quickly it delivers the first token to the user.

These signals are measured from the last 20 jobs only, using a rolling window. This means a worker that had a rough patch but recovers can regain its score naturally, and a worker that used to perform well but degrades recently will be caught quickly.

The Formula

score = (completion_rate × 0.5) + (tps_score × 0.3) + (ttfb_score × 0.2)

Completion Rate accounts for 50% of the score. It is calculated as the number of successfully finished jobs divided by the total number of assigned jobs. A worker that drops connections, times out, or fails to acknowledge job offers gets penalized here directly.

TPS Score accounts for 30%. It compares the worker's actual rolling-average tokens per second against its own registered benchmark. A worker hitting its benchmark scores 1.0 on this component. Exceeding it is capped at 1.2 and normalized back to 1.0. Falling short reduces the score proportionally.

TTFB Score accounts for 20%. It measures first-token latency how long the user waits before seeing any response. A latency of 500 ms or below scores a perfect 1.0. At 10,000 ms the score reaches 0. The curve is linear between those two points.

The final score is always a value between 0.0 and 1.0. Workers with higher scores are selected more frequently for incoming jobs through a weighted random selection not strict priority ordering, but proportionally better odds.

Auto-Suspension

If a worker's quality score falls below 0.15 for five consecutive jobs, it is automatically suspended. Its suspendedAt timestamp is written to the database and it is immediately excluded from the eligible worker pool. The suspension persists until the worker re-registers. This prevents the network from routing user jobs to a GPU that consistently fails to deliver acceptable results.
Failed jobs where the worker was assigned a job but timed out, dropped the connection, or never acknowledged the offer count against the completion rate and trigger the same scoring path.

Persistence

After every real job, the orchestrator writes the updated state to the database. This includes the latest quality score, the rolling average TPS, the current completion rate, and the running totals for completed and failed jobs. This means the score survives server restarts and reflects genuine lifetime performance rather than in-memory session state only.
Visibility

Workers can see their current quality score on the Earn page under the Native Worker tab. The display shows the overall score as a color-coded bar (green above 70, yellow above 40, red below 40), along with a breakdown of all three components individually completion rate, average speed in tokens per second, and average first-token latency in seconds. Workers that have been suspended see a banner explaining why and what to do to recover.